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?<p>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).<p>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?<p>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.
This looks more elegant than the hacked-together system I'm using for my passwords, but I don't see a way to store any metadata about the passwords other than the name.<p>If you're looking for a command-line interface to a cross-platform password database, there's kpcli for keepassx.<p><a href="http://kpcli.sourceforge.net/" rel="nofollow">http://kpcli.sourceforge.net/</a><p><a href="http://www.keepassx.org/" rel="nofollow">http://www.keepassx.org/</a><p><a href="http://search.cpan.org/~rhandom/File-KeePass-0.03/lib/File/KeePass.pm" rel="nofollow">http://search.cpan.org/~rhandom/File-KeePass-0.03/lib/File/K...</a>
Coincidentally, I've also been using a GPG based password manager called 'pass' for about ten years or so. I publish its source code here, straight from my version control system called <i>.bashrc</i>:<p><pre><code> alias pass='gpg -o - ~/Important/passwords.gpg'
</code></pre>
The <i>gpg</i> command will automagically use the relevant askpass dialog of the desktop of my choice, which I've set to expire after fifteen minutes. The above command will print a sorted list of entries in this format:<p><pre><code> site: username
site: password
</code></pre>
also known as a <i>text file</i> and extracting specific passwords goes by eyeballing the printed output or alternatively applying <i>grep</i> to only extract the stored data for a specific site. The final copying to the web browser happens via manual operation of mouse selection and the clipboard. I get rid of the plaintext passwords by actuating an operation called closing the terminal window.<p>Works just fine! And I got to choose the format of the datastore myself, too!
I was just recently looking for a simple password manager for Ubuntu, and Seahorse is <i>so close</i>. It unlocks with your login key so if you're logged in you don't have to keep entering a master password each time you need to retrieve a password; it stores everything in one easily-copyable encrypted file; and it's a core part of GNOME. <i>But you can't store any metadata about the password, like a username!</i> And that makes it completely useless as a serious password storage interface. What good is a password if you can't easily store the username along with it?<p>If only someone would update Seahorse to store optional metadata along with passwords...
I've written a number of filesystem-based databases, and the problem that always comes up is keeping the entries consistent. You don't want a password database where the master password is different between entries, but with this system, you can't enforce that invariant until it's too late.<p>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.<p>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.
I've been using (and updating) kedpm (python based FPM compatible password manager with GTK and CLI interfaces. found on sourceforce and github) for a few years now...<p>This looks like a nice addition to the growing menagerie of password managers.<p>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.<p>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.<p>With the ability to search (assuming it's fast), the first problem could be mitigated by using generated file names.
This looks nice. I've been doing something similar by hand for e.g offlineimap and msmtp passwords that I didn't want to store in plain text. I had planned on writing a similar utility to manage things, and it looks like now I won't have to. Thanks for sharing.
Hey, It's now got a nice Homebrew OSX port.
It's not accepted yet, so you'll need to go<p><pre><code> brew install https://raw.github.com/zx2c4/homebrew/master/Library/Formula/pass.rb</code></pre>
It stores entries names in plaintext? Not very secure. I'll rather have log.tmp file container (with all encrypted passwords inside) than passwords\gmail.gpg