GUI with QtPass and documentation

[Pantamis]

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 prs but 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 prs fully compatible with QtPass, already compatible on all OSs. QtPass allows the user to provide his own pass implementation in its settings but this requires commands compatibility. It works already a bit when you use prs binaries: 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 to prs. For example, if prs 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 generate maybe ?)

Another issue I have is that I don't fully get what could be diferent from the original pass . I see new commands like housekeeping and alias but I don't fully get the implication of using them. It seems also that prs recipients list does not detect the gpg ID I used with pass. More documentation on pass interaction would be great to be sure to not mess up the "imported" password store !

[Tim Visée]

I don't know if you plan to work on a GUI for prs but 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 prs fully compatible with QtPass, already compatible on all OSs. QtPass allows the user to provide his own pass implementation in its settings but this requires commands compatibility. It works already a bit when you use prs binaries: 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 to prs. For example, if prs 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 like housekeeping and alias but 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 list does not detect the gpg ID I used with pass.

Interesting! It should be in there, if listed in ~/.password-store/.gpg-id. Please report this as bug if it remains.

More documentation on pass interaction 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.

[Tim Visée]

Your recipients not being listed is possibly related to #16, if a keygrip is used rather than a key fingerprint.

[Tim Visée]

Requested QtPass support here: IJHack/QtPass#603

Waiting for a response/discussion on there. Closing this now.