atlas-engineer
Password Store: Support harvesting username via filename without decrypting
Is your feature request related to a problem? Please describe.
Currently, the Nyxt password manager integration with pass will query for a username by decrypting the secret file and searching for a key by one of the following names: login/user/username. This convention, however, is not the only one in common use.
Many users (myself included) choose to instead use the convention of including the username as part of the secret's filename (e.g.: [email protected]) so that it may remain easily and automatically disambiguated with other credentials in the same domain (e.g.: Microsoft SSO).
For illustrative purposes, here's what a password store directory using this format might look like:
graph TD
A["~/.password-store/"]-->B["example.com/"]
A-->C["sso.example.net/"]
B-->D["[email protected]"]
C-->E["[email protected]"]
C-->F["[email protected]"]
A-->G["[email protected]"]
class D,E,F,G secret
classDef secret stroke:#333
Because I follow the above convention rather than storing usernames as keys in the encrypted file body, my credential usernames cannot currently be retrieved by Nyxt when invoking copy-username. I'd very much like it if Nyxt was made to support this convention on an optional basis so that I could take full advantage of its password management features without having to considerably rework my existing setup.
Relevant prior art:
- Emacs auth-source
- Qutebrowser qute-pass
- rofi-pass
- Android Password Store (via PGPainless)
Describe the solution you'd like
When copy-password is invoked with the password-store backend active, I would like the backend to first attempt extracting the username from the filename. Ideally, it should be able to automatically detect and extract the expected username from each of the following common well-known filename patterns (source)
| Directory | Filename | Extracted Username |
|---|---|---|
| .password-store | [email protected] | me |
| .password-store | [email protected]:22.gpg | me |
| .password-store | [email protected]@example.org.gpg | [email protected] |
| .password-store | [email protected]@example.org.gpg | [email protected] |
| .password-store/example.org | me.gpg | me |
| .password-store/example.org | [email protected] | [email protected] |
| .password-store/example.org | [email protected] | [email protected] |
Describe alternatives you've considered I've considered abandoning this scheme and moving the username into the content of the secret file. This is probably viable, but I'd very much rather not rewrite and reencrypt hundreds of secrets when my current & preferred format is quite standard and commonly supported elsewhere -- not to mention that reencrypting hundreds of keys would take me hours since I am using a strict mandatory-touch hardware-based encryption.
I wrote an extension which extends the built-in pass interface with the above requested filename-based usernames capability.
If the dev team likes my implementation, I'm all too happy to port my work into the official password-mode. With that being said... I'm not in any particular rush, so for now I'll just leave the extension code linked below so that it can get seen the next time this issue would normally come up for review: https://gist.github.com/chaorace/98417a693ca73c51a8688ac09e61d2b0
@chaorace it's great that you were able to implement it, thanks!
We'd be eager to integrate your work in the project. Feel free to open a PR when you're ready.
In the meantime, see e08b99830.
