From ngraves at ngraves.fr Mon Mar 3 13:35:30 2025 From: ngraves at ngraves.fr (Nicolas Graves) Date: Mon, 03 Mar 2025 13:35:30 -0000 Subject: Allowing alternative encryption backends Message-ID: <87cyeyme3l.fsf@ngraves.fr> Hi pass! Bringing this conversation back to life! I'm very much in favor of bringing the option to add the possibility to handle Age in the password-store emacs package. IMHO, it's very much in the emacs' modern spirit to make "peer-dependencies" work well together with minimal configuration options (consult/vertico/marginalia/embark approach) instead of forking entire packages to add 3/4 options. The following reasons make it mandatory in the long run IMHO: - The package passage.el is mostly a full fork of password-store.el - limited developper time / need to keep the fork updated and using modern emacs features. And deduplication of efforts too (contributions could be merged from both sides). - it's most likely possible to add 3/4 options without denaturing password-store.el at all, even for the unsupported web-of-trust feature - using options make it easier to switch and try instead of having duplicates (e.g. if a user has 30 lines of password-store keymaps and configuration, no need to s/password-store/passage/ just to try, which makes it quite convenient for emacs frameworks which would rather not duplicate pre-configuration either). Cons : - What if a user wants 2 distinct stores / authinfo ? Is that compatible? I made an unreviewed patch in this direction a while ago : https://lists.zx2c4.com/pipermail/password-store/2022-October/004659.html A discussion followed on this subject but never converged in a decision. I'm proposing the following design: - port passage.el back in password-store.el - 3/4 configuration options should be enough to configure password-store with age instead of gpg - don't create an explicit dependency on age.el: - when age.el is absent, work as expected/current - but extend functionality when age.el is present (allow some additional configuration options) - for the web-of-trust functionality (not present in Age), simply return an error message when trying to use it "web-of-trust is not supported by Age backend". I'm willing to put in the work to bring that in password-store.el... if committers agree on the idea to port that in the package. The author of the package agrees on the objective : https://github.com/anticomputer/passage.el/issues/3 Before starting to work on that, I would like some feedback and an upstream committer to agree to work with me (reviews) for extending password-store.el to support age. WDYT ? Feel free to also document the pros/cons and amend the design proposition if I forgot something. -- Best regards, Nicolas Graves From org_password_store at xrad.org Sun Mar 9 12:30:48 2025 From: org_password_store at xrad.org (Conrad Hughes) Date: Sun, 09 Mar 2025 12:30:48 -0000 Subject: Editor backup files Message-ID: My editor (vim) creates backup files automatically, which in the case of 'pass edit' is something of a security leak ? it'll fill your editor backup dir with files like %dev%shm%pass.xyzxyzxyzxyzx%xyzxyz-passentry.txt~ One way around this is to configure the editor not to create backups when editing in /dev/shm. Have people taken any other approaches? Conrad From ngraves at ngraves.fr Mon Mar 10 10:37:19 2025 From: ngraves at ngraves.fr (Nicolas Graves) Date: Mon, 10 Mar 2025 10:37:19 -0000 Subject: Allowing alternative encryption backends In-Reply-To: <87cyeyme3l.fsf@ngraves.fr> References: <87cyeyme3l.fsf@ngraves.fr> Message-ID: <87o6y9kw84.fsf@ngraves.fr> Hey, sorry to push again, I really need this in order to switch back to GnuPG at a later date -- without changing my config, hence the requirements ; and ask for commit access on Guix. I'm willing to do the work, I just want a guarantee and feeback that it could be merged if the code is well-integrated. Cheers, Nicolas On 2025-03-03 14:35, Nicolas Graves wrote: > Hi pass! > > Bringing this conversation back to life! > > I'm very much in favor of bringing the option to add the possibility to > handle Age in the password-store emacs package. IMHO, it's very much in > the emacs' modern spirit to make "peer-dependencies" work well together > with minimal configuration options (consult/vertico/marginalia/embark > approach) instead of forking entire packages to add 3/4 options. > > The following reasons make it mandatory in the long run IMHO: > - The package passage.el is mostly a full fork of password-store.el > - limited developper time / need to keep the fork updated and using > modern emacs features. And deduplication of efforts too (contributions > could be merged from both sides). > - it's most likely possible to add 3/4 options without denaturing > password-store.el at all, even for the unsupported web-of-trust feature > - using options make it easier to switch and try instead of having > duplicates (e.g. if a user has 30 lines of password-store keymaps and > configuration, no need to s/password-store/passage/ just to try, which > makes it quite convenient for emacs frameworks which would rather not > duplicate pre-configuration either). > > Cons : > - What if a user wants 2 distinct stores / authinfo ? Is that compatible? > > I made an unreviewed patch in this direction a while ago : > https://lists.zx2c4.com/pipermail/password-store/2022-October/004659.html > A discussion followed on this subject but never converged in a decision. > > I'm proposing the following design: > > - port passage.el back in password-store.el > - 3/4 configuration options should be enough to configure password-store > with age instead of gpg > - don't create an explicit dependency on age.el: > - when age.el is absent, work as expected/current > - but extend functionality when age.el is present (allow some > additional configuration options) > - for the web-of-trust functionality (not present in Age), simply return > an error message when trying to use it "web-of-trust is not supported by > Age backend". > > I'm willing to put in the work to bring that in password-store.el... if > committers agree on the idea to port that in the package. The author of > the package agrees on the objective : > https://github.com/anticomputer/passage.el/issues/3 > > Before starting to work on that, I would like some feedback and an > upstream committer to agree to work with me (reviews) for extending > password-store.el to support age. > > WDYT ? Feel free to also document the pros/cons and amend the design > proposition if I forgot something. -- Best regards, Nicolas Graves