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

Previous Next

Full log

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

From: Arsen Arsenović <arsen <at> aarsen.me>
To: "J.P." <jp <at> neverwas.me>
Cc: Damien Cassou <damien <at> cassou.me>, Eli Zaretskii <eliz <at> gnu.org>,
 67937 <at> debbugs.gnu.org
Subject: Re: bug#67937: 30.0.50; auth-source-pass relies on epa-file being
 enabled
Date: Thu, 21 Dec 2023 16:29:25 +0100

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

Hi J.P,

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

> Hi Arsen,
>
> I too don't use the password store or auth-source-pass, but a couple
> dumb questions anyway (feel free to ignore):
>
> 1. Would it be possible to leverage the existing interface from
>    `epa-hook' for decrypting these files? As a dirty example:
>
>    (defun my-ensure-epa-file-name-handler (orig &rest args)
>      (require 'epa-hook)
>      (defvar epa-file-handler)
>      (let ((file-name-handler-alist
>             (cons epa-file-handler file-name-handler-alist)))
>        (apply orig args)))
>
>    (advice-add 'auth-source-pass--read-entry
>                :around #'my-ensure-epa-file-name-handler)
>
>    And if doing something like that (without the advice, obviously),
>    could we somehow "weaken" the regexp of our fallback member's key so
>    that `find-file-name-handlers' favors an existing, user-defined
>    override? Alternatively, would it be too wasteful to first attempt to
>    match the target file name against the option's current members
>    before falling back on binding a modified value (or using your
>    proposed hard-coded solution)? Or, wasteful or not, what about
>    instead offering a new auth-source-pass option whose value is an
>    alist of the same type as `file-name-handler-alist' that we use in
>    place of or concatenate with the existing value at runtime?

I don't think ensuring the epa-hook is added here is preferable when a
solution that doesn't rely on hooks (one using epg, like in the patch I
posted) is quite short.  Unless EPA does more than EPG for this (but it
does not seem to, to my novice eyes).

I'm not sure what you mean by 'hard-coding' here.  These files are
always gpg files (that's how pass works), and they are always OpenPGP
encrypted.  The usage of epg-decrypt-file is proposed by the help of
epa-decrypt-region IIRC.

> 2. How likely is it that someone actually depends on the perceived
>    undesirable behavior currently on HEAD? Like, for example, could
>    someone out there conceivably have a cron-like script that runs
>    `epa-file-disable' before copying the encrypted secrets from the
>    result of an `auth-source-search' to Nextcloud or something? If these
>    weren't passwords, perhaps we could just shrug off such
>    hypotheticals, but... (just saying).

I do not know, but this dependency is wrong either way, and can confuse
users and the auth-source cache.

The only reason I noticed this is because *something* (and I have no
idea what as of yet) somehow unhooks epa-file.  When I noticed that, I
figured I could use epa-file-disable to provide a simpler reproducer.  I
didn't actually notice the bug by using epa-file-disable (and I have
never intentionally ran epa-file-disable).

I'll be tracking that down next, but fixing this first seemed easier.

> Thanks,
> J.P.

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.