GNU bug report logs - #67937
30.0.50; auth-source-pass relies on epa-file being enabled

Previous Next

Full log

View this message in rfc822 format

From: Arsen Arsenović <arsen <at> aarsen.me>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: damien <at> cassou.me, Eli Zaretskii <eliz <at> gnu.org>, 67937 <at> debbugs.gnu.org, jp <at> neverwas.me
Subject: bug#67937: 30.0.50; auth-source-pass relies on epa-file being enabled
Date: Sun, 24 Dec 2023 17:11:47 +0100

[Message part 1 (text/plain, inline)]

Hi Michael,

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

> Arsen Arsenović <arsen <at> 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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.