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

[J.P.]

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.

Anyway, this is useful analysis. Thanks again for all your help.

0000-v6-v7.diff
Description: Text Data

0001-POC-Make-auth-source-pass-behave-more-like-other-bac.patch
Description: Text Data

0002-POC-Support-auth-source-pass-in-ERC.patch
Description: Text Data