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

[J.P.]

Kai Tetzlaff <emacs+bug@tetzco.de> writes:

> I've done some further checks and now it seems that setting
> `auth-source-pass-extra-query-keywords' to `nil' in a new emacs session
> does indeed fix the issue (maybe `auth-source' caching of the negative
> lookup caused my initial breakage to persist even after changing
> `auth-source-pass-extra-query-keywords').

Ah, right, the cache (gets me every time). BTW, it's probably still
worth mentioning the incompatibility in NEWS and the docs.

> The lookup which fails with the new code is for the following
> parameters:
>
> auth-source-search: found 0 results (max 1) matching
> (:max 1
>  :host ("news6.open-news-network.org" "onn6")
>  :port ("119" "nntp" "nntp" "563" "nntps" "snews"))
>
> My password store contains an entry for 'nntp/open-news-network.org'. I
> don't use the full hostname since the open news network has multiple
> servers (news1/2/3/4...) with the same domain name.
>
> Right now I don't have time for a more detailed analysis. But I will
> (hopefully) get back to it during the weekend.

Wow, thanks, this is really helpful. Based on that, I'm pretty sure
what's going on. Basically, the new behavior is geared toward blindly
replicating that of the other back ends, warts and all. But that means
some handy pass-specific features, like subdomain matching, are notably
absent. I've attached a demo patch that better illustrates this.

My main question for you is: do you think we ought to change the default
for `auth-source-pass-extra-query-keywords' to nil? What about
additionally demoting it from an option to a public variable intended
solely for use by dependent libraries instead of end users?

0001-POC-Allow-subdomain-matching-in-auth-source-pass-fin.patch
Description: Text Data