<div dir="ltr"><div>> Chris Down <<a href="mailto:chris@chrisdown.name">chris@chrisdown.name</a>> </div><div>> Hey,<br></div><div>></div><div>> On 2013-12-07 21:20:42 +0000, Matthew King wrote:</div><div>
> Yay.<br></div><div>></div><div>> > Thorough audit trail (optional).</div><div>></div><div>> No idea what this means, but if it's just attributing changes, why not</div><div>> just do it through git?</div>
<div><br>It's a fancy enterprisey way of saying everything (access attempts, overwrites, etc.) is logged. The audit trail can be kept in the same directory or not. I envision it being useful in conjunction with a network server front-end of some sort which can track access attempts.</div>
<div><br></div><div>> > Signable passwords (still quite hacky and entirely unused).</div><div>></div><div>> "Signable"? If you're referring to having it signed by PGP, that already</div><div>> happens implicitly as part of the encryption process.</div>
<div><br></div><div>I'm not entirely sure where I'm going with this. Basically there's a sign command which lets a specific key be used to sign the (encrypted) password store. Currently that's all that exists though I have sort of vague plans for git hooks which can merge a release tree when the requisite signatures (automatic or administrative) are met.</div>
<div><br></div><div>> > Git made entirely optional.></div><div>> Ouch.</div><div><br></div><div>It needs to be turned off with a switch (-g). It defaults to complaining and aborting if it's not there.</div>
<div><br></div><div>> > Splittable into API and CLI.></div><div>> In my opinion, overengineering.</div><div><br></div><div>Probably. I was recovering from a stomach bug this week. What this really means is that everything's done in reusable functions and the CLI parsing is all together at the end. If that got chopped off, the rest could be sourced into bash and the functions called directly. They don't have to be.</div>
<div><br></div><div>> > Insert/get/edit/delete multiple keys in one invocation.></div><div>> Yay.</div><div>></div><div>> > Pretty-print output. If each password requested is a YAML document,</div><div>
> > multiple passwords are returned as a YAML stream.</div><div>></div><div>> Ouch.</div><div><br></div><div>Again, off by default. Needs the -H switch. I needed some way to handle outputting multiple files. The first line is prefixed with "<path>: ". If the full file is requested, a line containing "---" is appended. If the encrypted document is YAML, the output with -H will be YAML. Either way it's easily human and machine readable. Without the -H switch the files are just dumped to stdout in the order requested.</div>
<div><br></div><div>> I see a lot of wordsplitting bugs which should be easy to fix. If you're<br></div><div>> not sure when it's appropriate to quote, you should probably be doing it</div><div>> all the time.</div>
<div><br></div><div>I'm fairly sure this caused at least one of the bugs I noticed. I plan to create and use a test suite of some sort for each component.</div><div><br></div><div>Matthew</div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 7 December 2013 21:40, Chris Down <span dir="ltr"><<a href="mailto:chris@chrisdown.name" target="_blank">chris@chrisdown.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey,<br>
<div class="im"><br>
On 2013-12-07 21:20:42 +0000, Matthew King wrote:<br>
> I feel really bad about writing a new version of pass, but I just kept on<br>
> hacking and it sort of happened. I emailed Jason before uploading this to<br>
> github but I got bored and hacked on it some more so I feel like I<br>
> shouldn't keep it to myself any more as I've not heard back from him.<br>
<br>
</div>I wouldn't feel bad about it, as long as you attribute correctly.<br>
<br>
Jason seems to reply sporadically even on this list, I wouldn't read<br>
into it too much. I certainly have patches still waiting from months ago<br>
due to that.<br>
<div class="im"><br>
> It takes basically the same filesystem structure as pass (the gpg key is<br>
> now stored in .keyids) and the command-line interface should be compatible,<br>
> but it changes the gpg interaction to add new features:<br>
><br>
> Multiple destination keys. The keys to encrypt to can be set on a<br>
> (recursively) per-directory and per-password level, and on the command-line.<br>
<br>
</div>Yay.<br>
<br>
> Thorough audit trail (optional).<br>
<br>
No idea what this means, but if it's just attributing changes, why not<br>
just do it through git?<br>
<div class="im"><br>
> Signable passwords (still quite hacky and entirely unused).<br>
<br>
</div>"Signable"? If you're referring to having it signed by PGP, that already<br>
happens implicitly as part of the encryption process.<br>
<br>
> Git made entirely optional.<br>
<br>
Ouch.<br>
<div class="im"><br>
> Splittable into API and CLI.<br>
<br>
</div>In my opinion, overengineering.<br>
<div class="im"><br>
> Insert/get/edit/delete multiple keys in one invocation.<br>
<br>
</div>Yay.<br>
<div class="im"><br>
> Pretty-print output. If each password requested is a YAML document,<br>
> multiple passwords are returned as a YAML stream.<br>
<br>
</div>Ouch.<br>
<div class="im"><br>
> With all that, however, it is a far less tested and documented project<br>
> (it's less than a week old), there are features I have yet to implement<br>
> (especially portability), and I have already noticed more bugs pass has<br>
> already fixed. I'm definitely not recommending people use another-pass<br>
> until it is more thoroughly vetted, but perhaps as a proof-of-concept.<br>
<br>
</div>I see a lot of wordsplitting bugs which should be easy to fix. If you're<br>
not sure when it's appropriate to quote, you should probably be doing it<br>
all the time.<br>
<br>
> Thanks, and sorry!<br>
<br>
I'm not sure why you're so apologetic :-)<br>
</blockquote></div><br></div>