bug#58985: 29.0.50; Have auth-source-pass behave more like other back ends
Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <[email protected]>
| Newsgroups | gmane.emacs.bugs,gmane.emacs.erc.general |
|---|---|
| Message-ID | <[email protected]> |
"J.P." <[email protected]> writes: > Akib Azmain Turja <[email protected]> writes: > >> "J.P." <[email protected]> writes: >> >>> 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". > > That's the effect, right. I think `directory-files-recursively' > basically determines the ordering in which the entries are considered. > >> 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 "[email protected]". But it returns the password >> in "foo.com/bar.org". >> >> I deleted "foo.com/bar.org", now it return the password of >> "[email protected]". >> >> I created "foo.com/bar.org" again, and "foo.com/bar.org" is preferred >> again. >> >> I suggest to prefer the "@" syntax over "/user" syntax. > > I have tried tweaking things in that direction. But as far as > deprecating the /user form officially: that seems more like a group > decision. And then there's the question of how to express such a policy. > Should we emit a warning? At the very least, it would need to be > documented somewhere. No, I didn't say to deprecate that syntax, the syntax makes much sense. I'm suggesting to return "USER@HOST" if both "USER@HOST" and "HOST/USER" are present, because the former makes more sense. > > Anyway, this is useful analysis. Thanks again for all your help. > > > > When are you going to install this? It's definitely an improvement over the one in master, and doesn't have any problems to block it. Installing it will also expose it to more users to the change, so this will get even more testing. -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: [email protected] Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption."
signature.asc
(application/pgp-signature, 832 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEyVTKmrtL6kNBe3FRVTX89U2IYWsFAmNyf7EACgkQVTX89U2I YWsJzRAApOKINyFhf1byr1qIOueTNcA5bBcHoJFVFQLmlJbXdpYOwHWwvcD36fsI X/tbft716CY6x262IXRmC0Yp2V7uiGsPVm+uy9eMTBVeLAYxbpcXY46StKzewORU PcSQLi4L8w9AqTcdoVSf6t50eYipDpY6zP9YgwdvdxKoiW4I2HvlgLtwxwsWLXPU TxZOjRAu9YUHPpf924Ckk/fpfy5phFgcl4ZLJLB9ksX0l8YJnL8NI5gsRqg98HV3 LwUPObuZpM7cwXxXaVa97Gvc3MfJhSZNFXxB4NzxyzGZELvizNssAFAlzrgeKEtj Dk1RfI5bqJKMiBkYoqiqdfNqtCgkf+jb0n29ITPvjGveJ1NP168I1RCtuMGO2FKa XJ0S7FBleACnwDrOPPQVdMwQH5livc9pdRYo20gKCc6WF4ZLSxwu0a4leAfDTFwv xMP4OIkg+WV4J1mrxDLpgnHdc1jl2Gx5mOD8m8oTWXuWjp433UNv0QeaEK9bmSrI BSbmmpg8c31wbl7J9bBp2KxYlKznz9Oej9bv0LQlDtRujSLEo1NK2oBTJLjzNKPG tvSIqUw2mBFixHCenh6NqrKupUp/61o10B5zNdM3tgLUtNTUbnzCh/s8hUGoSz1S 3WVKJ63zEEzLGT13hlw3FHt10wqJ3qeOWm/9MSLKZGyIRXwE/T4= =D88P -----END PGP SIGNATURE-----