Hi all,

Damien Cassou <damien@cassou.me> writes:

> I don't feel confident enough in this area to give any feedback (and I
> don't want to spend too much time getting confident enough). Maybe Ted,
> the author of auth-source, could be of a better help?

Totally fair! And I see you've already Cc'd Ted. Thanks!

                                . . .

Michael Albinus <michael.albinus@gmx.de> writes:

> I have added also another backend to auth-source.el (secrets.el). I'm
> not too familiar with the API, but I might be able to answer some basic
> questions. Hopefully.
>
> Of course, I cannot beat Ted.

That's very generous. Thank you. In fact, I've been playing around a bit
with the secrets back end and am pleased to report that it satisfies all
of ERCs expectations, making it the latest addition to the roster
alongside netrc, json, and plstore (integration tests for all attached).

While it may be tempting to single out pass, this part from the doc
string for `auth-source-search' says that ignoring :max and returning at
most one result is totally acceptable:

  :max N means to try to return at most N items (defaults to 1).
  More than N items may be returned, depending on the search and
  the backend.

Now, I suppose it's safe to assume those back ends in auth-source.el
already supporting :max will continue to do so forever and that the
proposed kludges for pass [1] are likewise safe (as long as we only ever
apply them to 27 and 28).

What I'd like to know is actually something Damien had had the foresight
to raise initially but that I was too dim to grasp fully in the moment:

> if auth-source-pass doesn't implement auth-source protocol, shouldn't
> we try to improve it instead of working around it in all users of the
> library? Am I missing something?

In truth, without such an addition (adding :max to auth-source-pass),
I'm not sure it makes sense for ERC to shoot for pass support at all. So
ERC aside, would such a change be worthwhile from the perspective of
auth-source, seeing as pass is technically already fully compliant?

Thanks everyone,
J.P.

P.S. A couple minor questions crept up while I was typing this (tacked
on below [2]), but feel free to ignore.


[1] The proposed workarounds currently depend on these internal
    functions:

    - auth-source-pass--get-attr
    - auth-source-pass--disambiguate
    - auth-source-pass--find-match-unambiguous
    - auth-source-backend-parse-parameters

    They also include functionality recently provided by this commit:

      commit b09ee1406205e8b6298411b9a18c1cd26e201689
      Date: Sun Jun 27 17:36:00 2021 +0200

      lisp/auth-source-pass.el: Support multiple hosts in search spec

      * lisp/auth-source-pass.el (auth-source-pass-search): Accept a
      list of strings for argument HOST.

[2] A couple (non-pass specific) questions:

    - Is there anything obvious to watch out for in our integration
      tests to avoid contaminating existing ones for auth-source or
      secrets?

      Right now, the only thing we attend to specifically is let-binding
      `auth-source-do-cache' around every test.

    - Are there any security-related gotchas to heed when retrieving a
      bunch of secrets in bulk and sifting through them?

      Currently, results are narrowed to the best candidate, and its
      secret is returned as a string for (relatively) immediate
      transmission. IOW, I don't think any obvious references to the
      discarded ones remain, if that matters.