[caladri]

I'm not sure I see how this is in-keeping with any Unix philosophy I've encountered. "Everything's a file" is good, yes, but this program is needlessly-specific when what it does need not be. This is just a tool for browsing a file hierarchy in which the files happen to be GPG encrypted, right?

Which one thing is this doing and doing well? Merely being command-line and somewhat file-oriented does not make Unix orientation. The utility has numerous sub-commands, many of which are simply wrappers for other commands, like find(1) or tree(1). An encrypted file-system or some other way of encrypting the password hierarchy would seem to be exactly all the value this adds over simply using the extant set of Unix command-line tools. Most of this functionality simply duplicates the shell and cat(1).

It doesn't do one thing and well, it seems to do a small number of very general tasks in needlessly-specialized ways requiring arcane and unfamiliar incantations. The password generation stuff makes a fine stand-alone Unix utility. But git integration in the same program?

This is a front-end which brings with it a considerable number of ideas about policy, rather than simply providing a tool. Most of what it does could be handled much more simply by the filesystem and the extant tools it leverages or reimplements.

[ralphtinner]

Lotta facets of unix philosophy. It manages passwords and it does that well. "pass -c HN/ralphtinner", and then my password is on the clipboard for 45 seconds. That's nice.

From TFA, the password generation is via pwgen.

Encrypted filesystems often require root privs or SUID helpers and don't have straight-forward ways to do key management and key expiration. This tool relies on gpg's already working agent.

[repsilat]

> From TFA, the password generation is via pwgen.

Seems strange to have the password generation "on the inside", though. That essentially means that `pwgen` is a strict dependency. Instead of writing something like

  pass generate Email/jasondonenfeld.com 15

the user should just type something like

  pwgen 15 1 | pass insert Email/jasondonenfeld.com

That way they don't need `pwgen` to install `pass`. It also means that all of the options to `pwgen` can be used without special effort or documentation.

I'd say the same thing about `xclip`, but it's probably not worth having to write something like

  pass -c Email/zx2c4.com | xclip -selection clipboard -l 1

(or however xclip is supposed to work).

[zx2c4]

Well, since pass is a shell script, and thus has no compilation, you don't need pwgen, and then you can just use "some-generator-program | pass insert blah" as you mentioned. For me, though pass generate Cheese 20 is a lot easier to remember than having to think about the options to pwgen. Pwgen, by default, makes passwords that are easy to remember, and there's some flag you have to hit to make them "truely random". I can't ever remember what this flag is.

With xclip, it's actually a bit more nuanced. You want this to be internal because I have some logic for removing the password from the clipboard after 45 seconds and putting the old clipboard contents back (if nothing else has replaced it in the meanwhile).

[akldfgj]

> my password is on the clipboard for 45 seconds.

That's not very secure. Why not send the password directly to the input manager (as keyboard events or what-have-you), so the password only is seen by the app that needs it, instead of every app the user is running?

[zx2c4]

Yea that sounds quite nice. Any suggestion on the best way to do this? I suppose there could be browser plugins that call out to pass, but what about a generic system? What would you recommend?

[zx2c4]

Exactly.