Re: bug#58985: 29.0.50; Have auth-source-pass behave more like other back ends

[Akib Azmain Turja]

"J.P." <jp@neverwas.me> writes:

> Akib Azmain Turja <akib@disroot.org> writes:
>
>> "J.P." <jp@neverwas.me> 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 "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.
>
> 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: akib@hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

signature.asc
Description: PGP signature