bug#67937: 30.0.50; auth-source-pass relies on epa-file being enabled

[Arsen Arsenović]

Hi Michael,

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

> Arsen Arsenović <arsen@aarsen.me> writes:
>
> Hi Arsen,
>
>>>> I disagree.  I think that involving the f-n-h-a mechanism for handling
>>>> PGP files ultimately introduces implicitly far more complexity, even if
>>>> the code is slightly briefer, precisely because of this dependency.
>>>
>>> I disagree with your disagreement, and agree with Michael here.  I see
>>> no maintainer's complexity in using file-name handlers that could be
>>> avoided by not using them: file-name handlers are, and will always be,
>>> an integral part of Emacs internals, so thinking about them as
>>> "complexity" makes no more sense than, say, thinking about GC as
>>> complexity.
>>
>> In that case, auth-source-pass should ensure it's there.  This is where
>> the complexity I refer to creeps in.  Now auth-source-pass needs to
>> alter and restore file-name-handler-alist as appropriate.  This means
>> that it has to get involved with global state, potentially impacting
>> other functions it calls.
>
> No, auth-source-pass should not enable it on its own I believe. It
> should fire an error, which hopefully produces a backtrace. This
> backtrace would help us to understand, what's up.

I doubt that it would produce a useful backtrace, because I doubt a
well-behaved let-binding is causing an error (as I said, when I notice
this bug, epa-file stops working everywhere, even long after a potential
let-binding would've been unbound, implying that it gets unset via some
other means).

Nonetheless, it is worth a shot.  I will inject a check into my
currently running Emacs and see what happens.

I think erroring is an acceptable solution, though (but I do not think
the same of returning nil).

>> It seems to me more reliable to alter EPA to provide an
>> insert-file-contents functions for direct use.  This is less composable
>> and elegant than file-name handlers, naturally, but it is also exactly
>> what a password-store read requires.
>
> No. There is no reason to implement this.

It would prevent a potential error (the one suggested above) when it is
clear how a file must be read (which is always, as password-store
entries are always exactly PGP-encrypted files).

I'm also not sure how complex the heuristic for emitting this error
would be.  (memq epa-file-handler file-name-handler-alist) is not
adequate as non-EPA handlers for PGP files could be active and/or
preferred.  (assoc (car epa-file-handler) file-name-handler-alist) is
also not quite correct as regexes not exactly equal to (car
epa-file-handler) could still match PGP files.

I'm willing to implement a solution if you know a better heuristic.

Thanks, have a lovely day.
--
Arsen Arsenović

signature.asc
Description: PGP signature