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

[J.P.]

Hi Michael,

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

> "J.P." <jp@neverwas.me> writes:
>
>> If those Tramp addresses don't continue to work after your suggested
>> changes, we should probably ask Michael Albinus whether their working
>> currently is just an accident or something intentional and supported.
>
> I don't remember any special effort making auth-source-pass Tramp-affin,
> but I might misremember. However, I wouldn't call it "accident", but
> "Emacs design". If accessing auth-source-pass-filename uses the well
> known primitive functions (insert-file-contents, expand-file-name
> alike), there shouldn't be a problem of keeping this compatibility with
> Tramp.

Ah, right. So deliberate by proxy (or virtue) of Emacs design, then. The
issue in this bug is that a default member of `file-name-handler-alist',
namely,

  ("\\.gpg\\(~\\|..." . epa-file-handler)

which is actually the value of the variable `epa-file-handler' added by
the file epa-hook, disappears mysteriously due to "reasons" TBD. This
breaks `auth-source-pass' because it relies on `insert-file-contents',
which calls `find-file-name-handler', to decrypt passwords. Arsen
believes this dependency a sign of unnecessary brittleness and therefore
a bug. His proposed solution is to use `insert-file-contents-literally',
which epa-hook doesn't subscribe to, as it only does

  (put 'epa-file-handler 'operations '(write-region insert-file-contents))

while `i-f-c-literally' does

  (let ((inhibit-file-name-operation 'insert-file-contents)) ...)

My initial concern was other (non-Tramp) file handlers possibly missing
out by our routing around `insert-file-contents', but without a concrete
example, perhaps that's unwarranted FUD. Anyway, thanks for weighing in.

J.P.