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

[J.P.]

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.