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
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?
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).
Thanks,
J.P.
This bug report was last modified 206 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.