Re: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC

[Michael Albinus]

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

> Hi all,

Hi,

A general remark: I haven't read the complete bug messages, so in case
I'm missing something pls point me to this. In fact, I'm focussing on
the auth-source releated problems; erc details are not important for me
just now.

Btw, I found it hard to scan a bug report with so many different
problems. Usually, it is more simple to discuss every problem in a
separate bug report, in order not to lose control. Except, all of them
are strongly dependent.

You have said somewhere there is an archive at
<https://jpneverwas.gitlab.io/erc-tools/archive/>. I cannot access this
URL. Is there another URL to be used?

> 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.

Indeed. In Tramp there are two calls of auth-source-search: One call in
order to retrieve the password, and there I use ':max 1' explicitly (see
`tramp-read-passwd'). And there is another function used for user/host
name completion, not looking for the password, and there I use ':max
most-positive-fixnum' (see `tramp-parse-auth-sources'). But the former
case could refrain from specifying :max.

> 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?

Making auth-source-pass conform to the auth-source API would always be a
good thing™. I don't know whether there exist already such a bug report,
otherwise I recommend you to write a new report.

> [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?

I don't believe. Just follow the usual recommendation for ERT tests:
make a temporary environment for the test (for example, create a
temporary auth-source-pass store), run your test, remove test data (for
example, remove the temporary auth-source-pass store). That's how the
tests in auth-source-tests.el and auth-source-pass-tests.el are
designed, IIRC.

Since you don't want to test auth-source-pass functionality explicitly,
you can of course use any other auth-source backend. The scenario is the
same, and you could even provide several test functions like
erc-tests--auth-source-netrc, erc-tests--auth-source-json, and alike.

>       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.

That sounds OK. Even better would be to use functions for the :secret
token, instead of the secret strings themselves. And call that function
when you need it.

> Thanks everyone,
> J.P.

Best regards, Michael.