GnuPG 2.0 vs. 1.4 locale; gpgme_set_locale
marcus.brinkmann at ruhr-uni-bochum.de
Mon Nov 27 12:35:46 CET 2006
On Sat, 2006-11-25 at 17:46 +0100, Albrecht Dreß wrote:
> I have two related questions regarding the locale treatment in gnupg and
> After upgrading from gnupg 1.4 to 2.0 I noticed that the behaviour of
> passing strings to pinentry changed if I e.g. just type "gpg --sign" on
> the terminal. The following table lists the locale settings, the encoding
> of the strings printed on the terminal and the encoding of the strings
> passed to pinentry:
> Application | terminal locale | terminal output | pinentry strings
> gnupg 1.4 | de_DE.ISO-8859-1 | de_DE.ISO-8859-1 | *de_DE.UTF-8*
> gnupg 1.4 | de_DE.UTF-8 | de_DE.UTF-8 | de_DE.UTF-8
> gnupg 2.0 | de_DE.ISO-8859-1 | de_DE.ISO-8859-1 | *de_DE.ISO-8859-1*
> gnupg 2.0 | de_DE.UTF-8 | de_DE.UTF-8 | de_DE.UTF-8
> Both versions use the agent and the Gtk+-2.0 pinentry version. As my
> environment is still set to latin1, pinentry gets confused if it gets a
> string containing /mixed/ character sets where the message is in latin1
> ("Sie benötigen eine Passphrase...), but the description of my key
> ("Albrecht Dreß") is in utf-8. Launching the agent with LC_ALL set to
> de_DE.UTF-8 makes things even worse as it calls pinentry with this
> setting, and then pinentry has no clue how it should call iconv to convert
> the latin1 string properly.
> Shouldn't the conversation between gnupg and the agent always be in utf-8?
Yes, I think so. That it isn't above for GnuPG 2.0 seems to be a bug.
Can you file a report at bugs.g10code.com?
> If not, gnupg /must/ ensure that the strings contain characters from only
> /one/ encoding. However, IMHO exclusively using utf-8 is the better
> solution as key descriptions may contain characters from any codeset.
> The second question is how gpgme treats gpgme_set_locale() when I call the
> gnupg backend. I mainly use gpg through the Gnome MUA balsa, which talks
> to gnupg through gpgme. In balsa, I tried to explicitly set a gpgme utf-8
> locale, but apparently this setting isn't fed through to gpg, i.e. it
> still runs with my "normal" (Latin-1) environment. A quick glance over
> the source shows that (in posix-io.c) a execv() call is used instead of
> execve(). How are the locales set in gpgme are supposed to work?
The locale setting is currently only honored for gpgsm, see
engine-gpgsm.c:gpgsm_new(). The main idea behind gpgme_set_locale is to
set GPGME to the same locale as the application (which GPGME can't do
for you because of thread safety issues).
I don't mind supporting locale setting for GnuPG. Do you want to work
out a patch? Otherwise it will probably be done when we run GnuPG in
server mode as well.
More information about the Gnupg-devel