bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Arsen Arsenović
Subject: bug#67937: 30.0.50; auth-source-pass relies on epa-file being enabled
Date: Sun, 24 Dec 2023 13:00:44 +0100

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arsen Arsenović <arsen@aarsen.me>
>> Cc: "J.P." <jp@neverwas.me>, Damien Cassou <damien@cassou.me>, Eli
>>   Zaretskii <eliz@gnu.org>, 67937@debbugs.gnu.org
>> Date: Sun, 24 Dec 2023 11:37:55 +0100
>>
>> >> 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.
>
> 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.

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.

Naturally, file-name handlers are integral and highly important (and we
had an example in this thread: Tramp support /just works/ due to them!
A thing of beauty, really), but this is a rare instance in which a
file-name handler is absolutely required for correct operation, rather
than supplementing existing functionality, which is why I see this
instance differently.

> P.S. Would people please not use "shorthands" like "f-n-h-a" and
> "a-s-p", but instead use the full names?  Those "shorthands" make the
> text harder to read, while OTOH typing them in full using M-/ is very
> easy and takes only a couple of keypresses.

Sure.  These became a bad habit of mine due to Emacs handling them
often.  Apologies.
--
Arsen Arsenović

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]