[pass] Wanted: Test Suite

[Von Welch]

>
> How about just doing something like `EDITOR=magic.sh pass edit`, where
> magic.sh is a shell script that uses sed(1) to modify the password?
>

Worked. Pushed.

Von


On Sat, Apr 19, 2014 at 2:13 PM, Von Welch <von at vwelch.com> wrote:

> Hi Lukas,
>
> On Sat, Apr 19, 2014 at 1:52 PM, Lukas Fleischer <info at cryptocrack.de>
>  wrote:
>
> > 2) "Building" pass. I figured out I really needed a version of the pass
>> > script to test with that has the platform-specific stuff replaced.
>> > Currently 'make install' is the only way to create a fully-functional
>> pass
>> > script, but I don't want to require installation for testing. Hence in
>> my
>> > branch I split the 'make install' process into 'make' which creates the
>> > platform-specific script and 'make install' which installs it. This lets
>> > you run 'make && make tests' without an install (actually 'make tests'
>> will
>> > do a 'make' if needed, but you get the idea.) Sound reasonable?
>> >
>>
>> Sounds good to me. However, the current Makefile adds a reference to
>> "/usr/lib/password-store.platform.sh" (shouldn't that rather be
>> "/usr/lib/password-store/platform.sh"?) to the shell script. So simply
>> splitting the Makefile target won't work.
>>
>
> You are right. It's only working for me because I previously installed
> pass. (I would assume you are also right about the typo.)
>
>
>> What I suggest is:
>>
>> * Rename password-store.sh to password-store.sh.in.
>>
>> * Use m4 (or some other tool) to inline the correct platform-specific
>>   code into password-store.sh.in and save the modified file as
>>   password-store.sh when running `make`.
>>
>> * Just install(1) the files when running `make install`.
>>
>
> Sounds reasonable to me.
>
> I think what I have is good enough to let me test and I'll see if someone
> else wants to take on rebuilding the make system.
>
>
>> > 3) 'pass insert' requires interactivity. It insists on asking for the
>> > password twice even if stdin is not a terminal (a pipe). We'll either
>> need
>> > to change that behavior, find some clever way of working around it for
>> > testing, or just decide it's not part of the test suite.
>> >
>>
>> What about `echo $secret | pass insert -e $pw`? Doesn't that work?
>>
>
> Ah, I missed '-e' turns off confirmation.
>
> Hmm, it does work, but for some reason returns a non-zero exit status.
> Some minor bug I assume.
>
>
>> > 4) Going further with regards to interactivity, I have no idea how to
>> test
>> > 'pass edit' at this point. I guess one could create a vimscript or
>> > something similar to simulate a user typing? Or just not worry about it
>> for
>> > the test suite.
>> >
>>
>> How about just doing something like `EDITOR=magic.sh pass edit`, where
>> magic.sh is a shell script that uses sed(1) to modify the password?
>>
>
> Good idea. I'll give it a try.
>
> Thanks,
>
> Von
>
>
> On Sat, Apr 19, 2014 at 1:52 PM, Lukas Fleischer <info at cryptocrack.de>wrote:
>
>> On Sat, 19 Apr 2014 at 18:56:34, Von Welch wrote:
>> > Jason, all,
>> >
>> > I've added a few more tests, enough to to find a few more issues. I'm
>> going
>> > to pause at this point and wait for feedback to see if we agree this is
>> the
>> > right path before doing more. The basic approach seems solid to me with
>> a
>> > few small issues/questions to resolve:
>> >
>> > 1) Unencrypted GPG key vs GPG-agent. Except for some weirdness with
>> 'pass
>> > init' with an unencrypted gpg key and a closed stdin, an unencrypted key
>> > seems to work well. It seems simpler than getting a gpg-agent running.
>> > Acceptable or do we really want to use an agent for testing?
>> >
>>
>> I would say it is fine to use an unencrypted key -- at least for the
>> very basic tests.
>>
>> > 2) "Building" pass. I figured out I really needed a version of the pass
>> > script to test with that has the platform-specific stuff replaced.
>> > Currently 'make install' is the only way to create a fully-functional
>> pass
>> > script, but I don't want to require installation for testing. Hence in
>> my
>> > branch I split the 'make install' process into 'make' which creates the
>> > platform-specific script and 'make install' which installs it. This lets
>> > you run 'make && make tests' without an install (actually 'make tests'
>> will
>> > do a 'make' if needed, but you get the idea.) Sound reasonable?
>> >
>>
>> Sounds good to me. However, the current Makefile adds a reference to
>> "/usr/lib/password-store.platform.sh" (shouldn't that rather be
>> "/usr/lib/password-store/platform.sh"?) to the shell script. So simply
>> splitting the Makefile target won't work.
>>
>> What I suggest is:
>>
>> * Rename password-store.sh to password-store.sh.in.
>>
>> * Use m4 (or some other tool) to inline the correct platform-specific
>>   code into password-store.sh.in and save the modified file as
>>   password-store.sh when running `make`.
>>
>> * Just install(1) the files when running `make install`.
>>
>> > 3) 'pass insert' requires interactivity. It insists on asking for the
>> > password twice even if stdin is not a terminal (a pipe). We'll either
>> need
>> > to change that behavior, find some clever way of working around it for
>> > testing, or just decide it's not part of the test suite.
>> >
>>
>> What about `echo $secret | pass insert -e $pw`? Doesn't that work?
>>
>> > 4) Going further with regards to interactivity, I have no idea how to
>> test
>> > 'pass edit' at this point. I guess one could create a vimscript or
>> > something similar to simulate a user typing? Or just not worry about it
>> for
>> > the test suite.
>> >
>>
>> How about just doing something like `EDITOR=magic.sh pass edit`, where
>> magic.sh is a shell script that uses sed(1) to modify the password?
>>
>> > Von
>> > [...]
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20140419/22d611af/attachment-0001.html>