Comment by rendaw
1 day ago
There's a ton of positivity here, but on the balance there are some significant issues with pass that I think bear mention:
- The fact that it's essentially unstructured data makes it hard to work with generically. If you have a username + password and need to use those in a script, you'll need to implement your own parser in your shell language in every script you need it in.
- `pass generate` to generate new passwords, maybe thanks to the above, replaces everything in the pass value by default. So if you had e.g. a password + secret question answers, if you use `generate` to get a new password it'll wipe out your secret question answers.
- It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful and IIRC the command line tools were very hard to use for reviewing/restoring passwords when you mess up updates, etc.
- The name makes it nearly impossible to search for
I've been working on something similar... although with slightly larger scope (intended to be used within containers/sandboxes) https://github.com/andrewbaxter/passworth
> It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful and IIRC the command line tools were very hard to use for reviewing/restoring passwords when you mess up updates, etc.
pass sets up a .gitattributes and configures git to convert gpg files to text via a custom driver. This enables a text-diff of the encrypted contents out of the box (at least for a store I've just set up to test this).
Thank you ! It was missed in my .git/config, probably because it expects gpg2, and my installation only has gpg. No diff works correctly!
Eek doesn't this create a security hole? Or are those diffs gpg encrypted?
Other significant issues I've had with `pass`:
- Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory...
- Hard to install if not packaged. I tried to install `pass` on a headless NAS, but it required gpg, which looked hard to cross-compile to aarch64.
- `pass` is a light interface over `gpg`. So it has all the problems of GPG – I've had a few annoyances with `gpg-agent`. Many organizations are trying to ditch GnuPG and switch to simpler and better cryptography tools, like age. https://github.com/FiloSottile/age
- Android with `pass` was a bad experience. The official package was unmaintained. The fork was not packaged in F-Droid. The UI was cumbersome.
I still use pass, for lack of an obviously better universal solution. There's FiloSottile/passage for minimal change, just replacing gpg with age, but no Android. A better alternative would be gopass, which is portable across all unixes, is compatible with `pass` and has an age plugin. But still no Android packaging. https://www.gopass.pw
> - Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory...
What do you mean? I copy my repo to new computers by just copying .password-store and I've never had a problem.
Isn't it just a git directory?
You should just `git clone that`.
If you move to age you will lose hardware backing though. No yubikey. That's the main attraction for me.
For the structure I "solved" that problem by creating folders with three main files:
Sometimes I add "/notes" with unstructured text contents, and for a few special cases I created a file "/json" with some machine-readable things in JSON format.
It's not perfect, and I do dislike the way that the metadata isn't encrypted, but on the whole I'm happy with the solution.
Yeah sure, but then are the conventions you came up with shared by all the tools in the ecosystem too (ex: browserpass)? Since the keystone (pass) declined to provide strong guidance, you end up with fragmentation and incompatibility.
I view this as a feature.
Yeah, but that's just your convention. I, for example, store password in
private/foo.com/foo-com-login
The first line of that file is password, the rest are optional notes. I think using first line for password and the rest for metadata was intended originally.
I love pass, but I agree that it would be nice to have an established standard of where to put username etc.
> - The fact that it's essentially unstructured data makes it hard to work with generically. If you have a username + password and need to use those in a script, you'll need to implement your own parser in your shell language in every script you need it in.
Fair, but you can use your own conventions.
> - `pass generate` to generate new passwords, maybe thanks to the above, replaces everything in the pass value by default. So if you had e.g. a password + secret question answers, if you use `generate` to get a new password it'll wipe out your secret question answers.
Just split it into `site/pass`, `site/secret-question`, etc. The fact that it's just using a directory tree is quite nice.
> It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful
`git diff` would be an odd command to run on generated passwords even without encryption. What matters is that you know when the last change was for a password or site with `git log <file/dir>`, and you can just `git checkout -d <old commit sha>` if needed.
> - The name makes it nearly impossible to search for
in the terminal `$ pass` typically suggests the associated package.
I assume they mean "search the web for", which is definitely a problem I've faced in the passt.
`pass git diff` decrypts the passwords for me.
"pass generate" has a -i flag to only replace the password in a file (assumed to be the first line)
> I've been working on something similar... although with slightly larger scope (intended to be used within containers/sandboxes) https://github.com/andrewbaxter/passworth
> stored in encrypted sqlite3
you had me at encrypted sqlite3. it would be great if you mention in readme that it uses SQLCipher
There is a bit of structure imposed if you want to use the provided automation for inserting passwords in the clipboard. The password comes as the first line. Then you are going to end up with the user name on the second line. Everything past that point is gloriously unstructured. I have a pass entry floating around here with an entire onboarding email in it...
You have to love how this whole thread embodies Cunningham's Law
https://en.wikipedia.org/wiki/Ward_Cunningham#%22Cunningham'...
For me the unstructured data is a big bonus. And it's not really unstructured. You can put Username: xxx and browser plugins like browserpass will pick that up.
There is an established convention for usernames, which is to put "user:" at the start of the line. It can't be the first line of the file but is otherwise not order dependent. The browser plugins and android app implement this and do autofill based on it. That is suggested on the main site.
If you blat your password with generate, it can be recovered because it is in git. A nice to have for pass might be a flag to autoinsert only on the first line, but in lieu of that, pwgen should do the job and is what pass uses under the hood.
> I've been working on something similar...
but this is not a shell script...