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

Previous Next

Full log

Message #77 received at 67937 <at> debbugs.gnu.org (full text, mbox):

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

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

Hi Michael,

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

>> No.
>>
>> This patch/bug report addresses a real problem that exists independently
>> of what triggered it in my case.
>
> The problem happens when epa-file-handler is removed from
> file-name-handler-alist, and no other handler responsible for *.gpg
> files is active. Understood.
>
> However, in normal use cases, nobody removes this handler. If I'm wrong,
> I'd like to iunderstand those use cases.

Based on observations during the last 24h I've noticed that many Emacs
functions do, in fact, reset f-n-h-a to nil.  I'm yet to spot the
combination of calls that leaves epa-file not added back in.

I know that it happens sporadically, though, and that it does not appear
to be via a let-binding, following passwords failing to fetch correctly,
I can't open PGP-encrypted files.  The latter fact is how I initially
figured to inspect auth-source-pass.

> So we must document, that auth-source-pass.el depends on such a
> handler. We could also add a check, that there is such a handler, and
> return either nil if it is missing, or return an error. As a first step,
> we could add a note in the manual, see (info "(auth) The Unix password store")

An error is preferable.  IIRC, auth-source caches negatives too.

> Just implementing an alternative doesn't sound the right way. This would
> also increase maintainance burden, if something changes how *.gpg files
> shall be handled.

I see where you're coming from.  I propose refactoring EPA to expose a
function to insert encrypted file contents as if via i-f-c, but without
requiring f-n-h-a as a solution to that issue.

That could lead to a more consistent user experience, too.

> As example, remote files won't work when tramp-file-name-handler is
> removed from file-name-handler-alist. It would be a strange approach to
> implement a Tramp alternative in packades depending on Tramp, just in case.

Correct.

The difference here is that password store entries are by definition
PGP-encrypted files.  They are not by definition possibly remote files
exposed via TRAMP.

The latter working is a nicety of Emacs design.  The former is crucial
to interacting with the password store.

>> Your gut's nearly certainly right here :-)  I am still hunting for the
>> cause of that issue.
>
> Good.
>
>> Regardless, what I said initially holds true ultimately: either epa-file
>> should not be relied on, or a-s-p should ensure it is present.  I
>> gravitate towards the former, as it reduces the complexity of getting a
>> password-store entry.
>
> I vote for the latter, because it simplifies overall maintainability.

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.

In addition, the user can't reasonably customize reading PGP files
substantially without breaking the contract with the password store.
This, to me, means that supporting that scenario isn't very useful,
especially in a program like Emacs, where any component can be changed
on the fly, leaving the user with the option of customizing more
directly.

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.