[pass] New version with new features

[Matthew King]

> Chris Down <chris at chrisdown.name>
> Hey,
>
> On 2013-12-07 21:20:42 +0000, Matthew King wrote:
> Yay.
>
> > Thorough audit trail (optional).
>
> No idea what this means, but if it's just attributing changes, why not
> just do it through git?

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.

> > Signable passwords (still quite hacky and entirely unused).
>
> "Signable"? If you're referring to having it signed by PGP, that already
> happens implicitly as part of the encryption process.

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.

> > Git made entirely optional.>
> Ouch.

It needs to be turned off with a switch (-g). It defaults to complaining
and aborting if it's not there.

> > Splittable into API and CLI.>
> In my opinion, overengineering.

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.

> > Insert/get/edit/delete multiple keys in one invocation.>
> Yay.
>
> > Pretty-print output. If each password requested is a YAML document,
> > multiple passwords are returned as a YAML stream.
>
> Ouch.

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.

> I see a lot of wordsplitting bugs which should be easy to fix. If you're
> not sure when it's appropriate to quote, you should probably be doing it
> all the time.

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.

Matthew



On 7 December 2013 21:40, Chris Down <chris at chrisdown.name> wrote:

> Hey,
>
> On 2013-12-07 21:20:42 +0000, Matthew King wrote:
> > I feel really bad about writing a new version of pass, but I just kept on
> > hacking and it sort of happened. I emailed Jason before uploading this to
> > github but I got bored and hacked on it some more so I feel like I
> > shouldn't keep it to myself any more as I've not heard back from him.
>
> I wouldn't feel bad about it, as long as you attribute correctly.
>
> Jason seems to reply sporadically even on this list, I wouldn't read
> into it too much. I certainly have patches still waiting from months ago
> due to that.
>
> > It takes basically the same filesystem structure as pass (the gpg key is
> > now stored in .keyids) and the command-line interface should be
> compatible,
> > but it changes the gpg interaction to add new features:
> >
> > Multiple destination keys. The keys to encrypt to can be set on a
> > (recursively) per-directory and per-password level, and on the
> command-line.
>
> Yay.
>
> > Thorough audit trail (optional).
>
> No idea what this means, but if it's just attributing changes, why not
> just do it through git?
>
> > Signable passwords (still quite hacky and entirely unused).
>
> "Signable"? If you're referring to having it signed by PGP, that already
> happens implicitly as part of the encryption process.
>
> > Git made entirely optional.
>
> Ouch.
>
> > Splittable into API and CLI.
>
> In my opinion, overengineering.
>
> > Insert/get/edit/delete multiple keys in one invocation.
>
> Yay.
>
> > Pretty-print output. If each password requested is a YAML document,
> > multiple passwords are returned as a YAML stream.
>
> Ouch.
>
> > With all that, however, it is a far less tested and documented project
> > (it's less than a week old), there are features I have yet to implement
> > (especially portability), and I have already noticed more bugs pass has
> > already fixed. I'm definitely not recommending people use another-pass
> > until it is more thoroughly vetted, but perhaps as a proof-of-concept.
>
> I see a lot of wordsplitting bugs which should be easy to fix. If you're
> not sure when it's appropriate to quote, you should probably be doing it
> all the time.
>
> > Thanks, and sorry!
>
> I'm not sure why you're so apologetic :-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20131207/c760cc3d/attachment-0001.html>