"J.P." writes: > Akib Azmain Turja writes: > >> Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife >> of text editors" writes: >> >>> "J.P." writes: >>> >>>> While I certainly welcome the assiduous scrutinizing of Emacs lisp >>>> mechanics and technique (truly), I was mainly hoping that, as an avid >>>> pass user, you would also help flesh out the precise effects of the >>>> behavior introduced by these changes and hopefully share some insights >>>> into how they might impact day-to-day usage for the typical pass user. >>>> Granted, that necessarily involves applying these patches atop your >>>> daily driver and living with them for a spell and, ideally, investing >>>> some thought into imagining common usage patterns beyond your own (plus >>>> any potentially problematic edge cases). If you have the energy to >>>> devote to (perhaps just some of) these areas, it would really help move >>>> this bug report forward. Thanks. >>> >>> Actually, I'm not very brave, and any damage to my password-store would >>> be an absolute disaster. >>> >>> However, I have made a backup and add the encrypted passwords to a Git >>> repository, and since the patch looks safe, I'm going to apply and test >>> it. >> >> I have applied the patch the on top commit f8c11b5a, and it works fine. >> >> I did some basic testing (manually) of auth-source-pass and the >> dependent packages I use, password-store and pass, and they all seem to >> be unaffected when the new option enabled. So I guess we can enable it >> by default. I didn't felt the need of test with the new feature >> disabled, since the patch doesn't touch any old code. > > Awesome. Thanks for all the work. I know it's kind of a hassle. > >> And I also found that, auth-source finds the entry "akib@disroot.org" >> correctly with (auth-source-search :host "disroot.org") when the new >> user option is set to t. > > Yeah, it's sometimes tricky to tell if the new code is even running, so > it's great that you checked that. I'm pretty sure the new code was running, since I set auth-source-do-cache to nil to disable cache prior doing the tests. > >> However, I haven't still installed the Emacs build with the patch >> applied as my daily driver, I'm working on that. The tests were >> performed on Emacs build without GUI. > > OK, nice. > > You mentioned previously some potentially surprising ambiguities > surrounding the trailing /user syntax. If any realistic scenarios > present themselves, perhaps we can try to improve the situation if it's > not too far out of scope (or just document the behavior, maybe in a unit > test). Thanks again. I think it's good enough to install on master. Then more people can test and report about it. However, observed some behavior of the new code, here are my findings: The new searching code seems to prefer "HOST/USER" over "USER@HOST". I created the password store entry "foo.com/bar.org". Then I evaluated: (warning: manually typed with hands) (auth-source-search :host "bar.org") ;; => nil (auth-source-search :host "foo.com") ;; => ((:host "foo.com" :user "bar.org" :secret ...)) I created another entry "bar.org@foo.com". But it returns the password in "foo.com/bar.org". I deleted "foo.com/bar.org", now it return the password of "bar.org@foo.com". I created "foo.com/bar.org" again, and "foo.com/bar.org" is preferred again. I suggest to prefer the "@" syntax over "/user" syntax. -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption."