bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus

[Robert Pluim]

>>>>> On Sun, 29 Mar 2020 16:52:18 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Lars Ingebrigtsen <larsi@gnus.org>
    >> Cc: Juan José García-Ripoll
    >> <juanjose.garcia.ripoll@csic.es>,
    >> 40248@debbugs.gnu.org
    >> Date: Sun, 29 Mar 2020 09:48:59 +0200
    >> 
    >> Eli Zaretskii <eliz@gnu.org> writes:
    >> 
    >> > +      ;; The caller might have bound coding-system-for-* to something
    >> > +      ;; like 'no-conversion, but the below needs to call PROGRAM
    >> > +      ;; expecting human-readable text in both directions (since we
    >> > +      ;; are going to parse the output as text), so let Emacs guess
    >> > +      ;; the encoding of that text by its usual encoding-detection
    >> > +      ;; machinery.
    >> > +      (let ((coding-system-for-read 'undecided)
    >> > +            (coding-system-for-write 'undecided))
    >> 
    >> I think this probably is the right thing here, but I'm not 100% sure --
    >> I seem to remember there being some issue of people putting non-ASCII
    >> stuff in the name parts of the gpg data and then Emacs having a problem
    >> of matching that up to the data we're looking for...

    Eli> If that non-ASCII data is compatible with the default encoding, or if
    Eli> Emacs will detect the encoding correctly given 'undecided', that
    Eli> shouldn't be any problem.  And this function is only about getting the
    Eli> gpg configuration, so what kind of non-ASCII data is expected there?
    Eli> And how would using 'no-conversion' here help?

    Eli> If you can find those cases where you saw non-ASCII data in this case,
    Eli> by all means describe them or point to relevant discussions.

My (admittedly fallible) memory is that gpg always uses UTF-8 for
non-ASCII data (except for some old versions that %-escape it instead).

Robert