timvisee
commented
1 year ago I don't know if you plan to work on a GUI for
prsbut that would be a great thing to have ! I love the idea of having a fully featured implementation that is compatible with all OSs, windows in particular but users are often using GUI on such distro.
Yes, I do plan to implement a full GUI for prs. This will use prs-lib internally to natively support pass stores like the CLI currently does.
I haven't done this yet due to limited time, but would love to work on this. Same goes for integration with web-browsers.
A nice possibility that requires less work than coding a whole GUI for you is to make
prsfully compatible with QtPass, already compatible on all OSs. QtPass allows the user to provide his ownpassimplementation in its settings but this requires commands compatibility. It works already a bit when you useprsbinaries: I can read passwords' content with QtPass. However I can't generate them, I can't get the totp and I don't think I can get the recipients. But I think it could be simple to handle by adding legacy CLI toprs. For example, ifprs totp [FILE]would just return the OTP if no other subcommand would be provided then it should be possible to support OTP in QtPass without any other change.
Thanks for the suggestion! I am aware QtPass exists but didn't know it could use use pass (or prs) as interface.
I don't think I'll make the CLI compatible with pass itself. That is because the main reason I started prs is to have a better (less ambiguous and more clear) CLI interface. Maybe it's possible to add prs support in QtPass itself, a useful addition because prs is properly multi-platform. Perhaps there's a nice middle ground here to get this to work.
Another issue I have is that I don't fully get what could be diferent from the original
pass. I see new commands likehousekeepingandaliasbut I don't fully get the implication of using them.
The most important things are listed here, with some of them being:
- proper support for multiple recipients (GPG keys), automating key importing amongst other things to make this as smooth as possible
- built-in & automatic support for synchronization between multiple machines using git
- built-in & automatic support for Tomb to prevent metadata leakage
- better interface for secret selection
- better clipboard management
I used gopass before for synchronization but decided to implement prs because it had many issues (weird errors, inconsistent commands, very noisy output, cumbersome interface). The main purpose of prs was to be a lot more convenient, automated and less cumbersome to use on a daily basis.
Both housekeeping and alias commands are safe to run. housekeeping provides useful utilities. alias provides an interface to alias a secret under multiple names. This uses symlinks under the hood which should be supported by other pass implementations. prs is alias/symlink aware however which makes using them better. For example, when showing an aliased secret, it will output the target secret, or when deleting an alias it will also delete the target secret.
It seems also that
prs recipients listdoes not detect the gpg ID I used withpass.
Interesting! It should be in there, if listed in ~/.password-store/.gpg-id. Please report this as bug if it remains.
More documentation on
passinteraction would be great to be sure to not mess up the "imported" password store !
I agree. Adding documentation is definitely something to work on. Especially documenting the differences between pass and other implementations.
Don't worry about messing up your store though. All commands should keep your store intact.
If you want to be extra careful, you may (automatically) version your store with git by running: prs sync init
I hope this answers your questions! Please let me know if you've more questions.
I just share some direction I find interesting for your nice project if you need some ideas to continue working on it :), feel free to ignore if you don't have time !
I don't know if you plan to work on a GUI for
prsbut that would be a great thing to have ! I love the idea of having a fully featured implementation that is compatible with all OSs, windows in particular but users are often using GUI on such distro.A nice possibility that requires less work than coding a whole GUI for you is to make
prsfully compatible with QtPass, already compatible on all OSs. QtPass allows the user to provide his ownpassimplementation in its settings but this requires commands compatibility. It works already a bit when you useprsbinaries: I can read passwords' content with QtPass. However I can't generate them, I can't get the totp and I don't think I can get the recipients. But I think it could be simple to handle by adding legacy CLI toprs. For example, ifprs totp [FILE]would just return the OTP if no other subcommand would be provided then it should be possible to support OTP in QtPass without any other change.That's say it could break some CLI you already made (like
prs generatemaybe ?)Another issue I have is that I don't fully get what could be diferent from the original
pass. I see new commands likehousekeepingandaliasbut I don't fully get the implication of using them. It seems also thatprs recipients listdoes not detect the gpg ID I used withpass. More documentation onpassinteraction would be great to be sure to not mess up the "imported" password store !