GNU bug report logs - #40248
27.0.90; Failure open .authinfo.gpg from Gnus

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: juanjose.garcia.ripoll <at> csic.es, 40248 <at> debbugs.gnu.org
Subject: Re: bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus
Date: Sun, 29 Mar 2020 16:52:18 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Juan José García-Ripoll
>  <juanjose.garcia.ripoll <at> csic.es>,
>   40248 <at> debbugs.gnu.org
> Date: Sun, 29 Mar 2020 09:48:59 +0200
> 
> Eli Zaretskii <eliz <at> 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...

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.