Nice read. I'm looking forward to try out a bunch of those things. But my favourite part is the SOCKS proxy. It reminds me of simpler times, when we used this to freely use the schools wifi, which had an overly restrictive web proxy.
But i think the UI needs improvement, and core features like master passphrase updates are still missing.
Also the clipboard handling could be improved (depending on the platform).
Im not sure yet, if and how browser integration or iOS/Android clients could or should work with passmgr, but if i have time i will think about it.
It depends on how you use it. As long as the identifiers are not visible to anyone else (like you described), its okay.
But if you sync your secrets across devices, using services that are not under your control, or your device gets stolen, more information than necessary got leaked.
Personally i dont see the point in integrating synchronization features for now. There are already tools which are good at synchronizing files.
And since everything is stored in a single file, it should be trivial to setup sync. E.g. you could do so with an alias like:
alias passmgrgit='git pull; passmgr -file xxx; git commit -a -m "updated";git push'
You are right, the 6 second limit is on the low end. Ther is also a timeout for general inactivity which is currently set to 60 seconds. I want to make them both configurable and provide better defaults.
The storage of arbitrary secrets is definitly on my todo list.
As for the git integration i do not see the point of having it. For someone who is able to set up a remote git repo, it should be trivial to use git for synchronization, even without "git integration", since everything is stored in a single file.
I have not yet looked into browser integration or clients for mobile platforms, but maybe there is a way to integrate with existing apps/extensions.
- You never ever lose anything. Updated the wrong password? No problem, just `git reset`
- Having everything in it's own file let's you merge changes made on different machines (I use this all the time, I'm not keeping every machine always up-to-date). If everything's in a single file, any change would result in a hard to resolve merge conflict.
- All the other git goodness, including file history (e.g. when was the last time I changed this password), mutliple users (e.g. a shared family store), and more
While some of these are debatable and git isn't really made for binary data, I still think it's a very good fit.
Featurewise, no (not yet).
However i think my aproach, using a single encrypted file for all secrets is somewhat more secure as it does not leak information like what sites are managed by the password manager.
I guess you could also argue that by using AES, passmgr has the advantage of being post-quantum secure, if that is important to you.
On X11 you can do better: the clipboard isn't actually stored anywhere, the program requesting the paste gets the data directly from the program that claimed the clipboard.
The clipboard lib you're using just spawns xclip (or xsel) on Unix. xclip has a -loops argument that is the maximum number of pastes. So you could just spawn:
xclip -loops 1 -in -selection clipboard
And the password would be available to paste exactly once. Unfortunately I don't think xsel has any such option.
There are clipboard manager apps that could grab the paste immediately and persist it, but I'm not sure how common they are or if they are default anywhere.
The main difference is, that passmgr uses authenticated symmetric encryption (aes-gcm) to store the contents in a single file, while pass as you already mentioned stores each secret in a separate file, using asymmetric encryption provided by gpg.
Storing secrets in separate files could leak metadata, especially when using a public git repository for synchronization between devices.
Other than that, you dont have to deal with gpg key management in passmgr.
I did something similar with a project for Node.js called nermal[1], which comes with an example called `tagaloop` that I still use to store my passwords. Even though it had a bit larger of a scope (it is a library for encrypting/decrypting arbitrary JSON with AES-GCM + scrypt + random-length-padding), one of the examples is a password manager called `tagaloop`. It did not really get the sort of traction that I hope you're going to see -- good luck! Fortunately I can still call it a success because it has made my life much easier in many cases.
We both can make different choices and that's OK, but I'm happy to see as a design point that both of our password managers are interactive loops to avoid the history management of the shell. I will say, though, that my files routinely hold way more than 4 passwords and listing them all for the user to choose by number is not really appealing: so one of the biggest things that `tagaloop` does is that it just lets you grep through them at the interactive console. You might want to consider that as a very important feature.
I think there are many users or who dont want to setup gpg on multiple machines. I can also imagine scenarios where it is simply not possible to setup gpg on every machine. Maybe you could workaround such scenarios with portable versions of gpg or something like yubikey.
However i like the idea of having a single binary with a minmal set of dependencies, which can be moved around easily wherever i want to use it.
