The point is to avoid the horrible bloat of 1pass and kees. I don't want a new database format. I just want simple files in simple folders, nothing fancy, nothing schmancy, easy to maintain, portable, standard.
I've been happily using 1Password for years now and have always been very happy with it. It syncs via Dropbox and I can access it anywhere I want. I have it on my Android phone via their Android reader. I don't see it as being horrible bloatware at all, in fact quite the opposite
I agree. Also, a common misconception is that your passwords are uploaded to a server with 1password. They are not! They are local on your machine, and you can optionally sync across your devices via your own dropbox account.
So do I, but I don't see where you enter the master password to access it before typing "pass". If I walk away from my desk for a minute or two, and someone points my browser at my bank, he'll have to enter a password. If he tries to ssh to my server, he'll have to enter the password. If he tries a sudo, he'll have to enter a password. I assume someone who typed "pass" at my command line wouldn't be given full access to my entire password store without having to enter, well, a password, right?
All the password management is handled by gpg-agent, which can be set to time-out your credentials after X seconds, on screen lock, when a bluetooth device moves out of proximity, or when it senses a disturbance in the force, as if millions of Macintosh users suddenly cried out in terror, and were suddenly silenced.
Gpg-agent is super awesome and flexible. Google it -- you'll dig it.
Yes, gpg-agent is super fancy, and if you and I weren't talking about the joys of "simplicity," I can see how it could be quite useful. (And thanks for pointing it out. If my needs get fancier, I might well decide to use it.)
But, for the moment, we ARE talking about simplicity. I'd like to simply encrypt a plaintext file. Then I'd have a decrypting version of cat (call it "dcat") that asks me for a password, doesn't echo it, and applies it to the file before cat'ing. It doesn't know if the password is right or wrong; it just passes the file through it before cat'ing. If I give it the wrong password, gibberish comes out.
I could then view a whole file (dcat my_secret_pancake_recipe.txt) or pipe it to grep (dcat my_logins.txt | grep -A 2 Netflix) to get just the lines I want---exactly what you'd do with any text file except that it starts with a decryption that asks for a password (which it doesn't echo).
What's the best way to do something this simple?
UPDATE: openssl essentially does this and comes already installed on Mac OS X. I'm a crypto noob, though, so I'd still welcome advice.
But GPG in general is the de facto unix way to go about crypting things. Straight up openssl is good for somethings, making little shell scripts like "dcat" is nice for others, but for general purpose encryption of files, nothing really beats GPG.
I guess GPG isn't simple. It's a big project, well-vetted, and has been under development for years. The usage of its tools, though, is very simple, and the file formats have now become an acceptable standard, widely adopted all over.
So really, give GPG another shot and a close look before you knock it. If it still doesn't meet what you're looking for, check out the man page for openssl-enc. Probably what you want is something like "openssl enc -aes-256-ofb -in infile -out outfile -salt", but likely there are other nuances to account for too. Be careful with crypto.
If I walk away from my desk for a minute or two, and someone points my browser at my bank [...]
To do that someone would already have to have typed your OS password to unlock your screen, right? If you're in the habit of leaving your system unlocked when you're not around it, you're already inviting someone to install a keylogger.
Not that interested in kludging around with whatever interfaces and python helper scripts and exporters and importers and yada yada. I just want passwords in simple text files with no frills, and so should you. The Unix Way. This password stuff isn't that complicated, yet every other solution out there introduces such needless complexity. Slim things down, get back to the basics, and you'll have simpler but more efficient machines that can stack together in more robust ways.
Complexity in implementation maybe, but certainly not in usability. The browser integration is awesome. Click, enter master password (if authentication session inactive), click, done. A "simple" commandline tool makes the UX needlessly complicated. Open terminal, type 'pass name-of-file' (or if you don't remember it exactly, list all files, copy its name, paste), enter password EVERY TIME, copy username, paste, copy password, paste, close terminal.
My computer has 8 GB of RAM for a reason. Let's use that to save me time and pain. The unix way is great and all, but it doesn't always make sense from the user's perspective.
With 1Password, you don't even have to click. You can just use the Command+\ shortcut in any browser, enter your 1Password password, press enter, and have 1P autofill and login.
You're missing his point. pass looks cool and is the 'right' way to do it from a unix perspective. However for the vast majority of people out there, 1password and others are much more usable because they can access them from their phones without using a terminal and automatically fill in passwords with their browser.
It sounds like pass has the potential to do these things as well, and I would prefer to use an open platform over a closed one, all things being equal. Just recognize that there are tradeoffs.
I don't think there's any trade-off here. If you want a mobile app that isn't text based, a desktop app that isn't console based, or a browser auto-fill plugin, then it's fairly trivial to write one, considering the extremely simple design of pass. So stop whining, and write this component; it's easy. There is no trade-off. Full feature parity is a possibility.
I wasn't referring to the tradeoff between plain text formats and usability, I was talking about the tradeoff between 1password and pass as it is today. I realize the apps can be written, and I think it has the potential to be better than those other password managers.
So stop whining, and write this component; it's easy.
You would get a lot further in convincing people to use and contribute to your app if you toned down the condescension. I like your app and support unix tools with open formats but you come across as someone who would be very difficult to work with.
You're right to say that a < 250 line shell script doesn't match 1pass's bloat. But there are ways, and there will be ways to make all this happen, ways that are nice and clean and pretty, and don't add much additional complexity, as you've acknowledged.
Sorry you're put off by my dismissal. My inbox is filled with awesome patches and suggestions from people, and things have been going pretty smoothly with integrating these and fleshing out new features. You seem optimistic about the project (" I think it has the potential to be better than those other password managers"), and so if you've got the impetus to contribute some code or suggestions, by all means send me an email.
