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.
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.
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
pwgen 15 1 | pass insert Email/jasondonenfeld.com
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
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).
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?
alias pass='gpg -o - ~/Important/passwords.gpg'
Works just fine! And I got to choose the format of the datastore myself, too!
If you're looking for a command-line interface to a cross-platform password database, there's kpcli for keepassx.
$ p news.ycombinator.com
Edit: I see now that this is just a shell script as well. Nice. I might take some ideas from it such as auto completion
Anyway, perhaps this is appealing to you:
Check out the source of pass -- it's probably pretty similar to your bash aliases. In fact, pass for me used to be a bash alias too.
That is the headline feature IMO (rather than 'standard')
edit: I should add that what gave me the impression of this being an application rather than something I would really use was the way it was presented with 'install', makefiles etc. rather than 'here are 30 lines of bash you can dump into your rc file'
I already say " It is a very short and simple shell script. " in the first paragraph. Maybe I should say something else too. Thinking...
Edit: responding to your edit: Yea, there's a lot of cruft that gets added to a source directory when you try and make anything on Linux into something suitable for /usr/bin and /usr/share/man. C'est la vie.
If only someone would update Seahorse to store optional metadata along with passwords...
Most importantly, a simple GPG file is not an obscure file format.
For me, unlock on login is essential. If someone beats me unconscious and steals my computer while I'm in a logged-in session, I have bigger things to worry about than a potentially lost password database.
On a tangential note, we as a hacker community really have to work on de-mystifying public/private keypair encryption. It gives me a headache to think about it and I've been a programmer for over a decade. If it does that to me then it's utterly unfathomable to laypeople and they're the ones who could make the most use out of strong encryption, and who could become the champions of privacy and security in the NSA-snooping age. But it's just too hard to explain and use.
I prefer having the key + passphrase over just a passphrase. It makes it more difficult for the information to leak.
That said, if you'd like a pass with a gpg -c mode, it shouldn't be hard to add. I could do this, or you could send a nice git formatted patch. Let me know.
(Although as a CLI program I suppose the argument could be made that non-techies will ignore it on principle anyway...)
I wonder how this compares to factotum.
A better idea might be a system where the canonical source of truth is an application-controlled database, but where you can export entries to a directory tree and import entries from a directory tree. This makes syncing more difficult (export to directory tree on both sides, rsync, import on both sides), but it ensures that invariants are checked at sync time rather than use time.
I suppose you can write a validation command that you always run after sync, but how many people are going to run that? You don't realized you've been burned by having an extra password for an obscure site until that happens.
For me, I love this, because I can secure passwords using my private key, stored on a GPG card. Of course, there are probably less than 250 people on earth doing that. :)
GPG is mostly easy to use -- gpg -e -r firstname.lastname@example.org file.txt -- will encrypt that file for that recipient. Most of the basic stuff are easy. For creating a key and setting that up, I suppose this isn't super intuitive and nobody has those commands memorized, but there are so many guides out there for doing this. I think I started with the gentoo gpg guide [http://www.gentoo.org/doc/en/gnupg-user.xml].
Anyway, you're correct -- this is one of the reasons pass uses GPG.
In any case, the GPG files have the ID of the key needed to decrypt them, so you can encrypt files with different keys, and so long as you have that key in your keychain still, you're good.
I guess I could add a simple convenience command "pass normalize" that decrypts everything and re-encrypts it using a single key. This would be a pretty simple way of doing it.
This looks like a nice addition to the growing menagerie of password managers.
All kedpm data, including entry names, are stored in an encrypted file. I think unencrypted filenames is a kind of information leakage; I may not want an attacker to know that I even a password to a specific service.
Also, I don't see a mechanism to search for entries. I have hundreds of password entries so search (on any field) is critical for me.
With the ability to search (assuming it's fast), the first problem could be mitigated by using generated file names.
For search, just use grep. "pass | grep whatever" has worked pretty well for me when the tab completion did not. Or would you suggest an alternative approach? I'm open to ideas.
Yeah, 'pass | grep foo' would work for search. I missed the default behaviour.
brew install https://raw.github.com/zx2c4/homebrew/master/Library/Formula/pass.rb
There's the difference, I think; I shred all my personally identifiable trash (well, recycling, actually).
Nice app by the way.