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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.