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

Previous Next

Full log

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: juanjose.garcia.ripoll <at> csic.es, larsi <at> gnus.org, 40248 <at> debbugs.gnu.org
Subject: Re: bug#40248: 27.0.90; Failure open .authinfo.gpg from Gnus
Date: Mon, 30 Mar 2020 16:10:34 +0200

>>>>> On Mon, 30 Mar 2020 16:10:15 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
    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).

    Eli> Is that true even on MS-Windows?  can someone please verify that?  If
    Eli> gpg uses UTF-8 on all platforms, the 'undecided' isn't TRT, as in some
    Eli> cases Emacs could mistakenly decide the encoding is the current system
    Eli> codepage.  We should use 'utf-8' instead if UTF-8 is guaranteed.

Having now re-checked it, I was wrong. gpg uses UTF-8 consistenly
_internally_, but converts to/from whatever it thinks the native
codepage is (on MS-Windows and unixy platforms).

Robert

Previous Next

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