Page MenuHome GnuPG

Kleopatra: Encoding problems with GnuPG output on Windows
Testing, NormalPublic

Description

Notices with refresh-keys but I also had this on other places where Gpg Output was used in Kleopatra.

I think that stringFromGpgOutput (I think that is what is called) might be wrong now that GnuPG trys to always output UTF-8

Reproducable with German l10n and refresh-keys. Both the output window and the error message (if there is an error) have broken umlauts.

Related Objects

Event Timeline

aheinecke triaged this task as Normal priority.Apr 29 2022, 2:19 PM
aheinecke created this task.

I would love to defer those encoding problems to gpgme. The output of gpgme should always be UTF-8 encoded, so that higher API doesn't need to bother about encoding. Obviously, this would mean that we shouldn't bypass gpgme by running gpg commands with QProcess.

It's a pity that gpg's --display-charset "should not be used on Windows" (the man page). Because I wanted to propose to force gpg to output UTF-8 on Windows, so that we can be sure that we are dealing with UTF-8. But I guess there's a reason why that's not done on Windows.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

stringFromGpgOutput is used by

  • DumpCertificateCommand
  • DumpCrlCacheCommand
  • ImportCrlCommand
  • GnuPGProcessCommand which is the base for
    • ClearCrlCacheCommand
    • ExportOpenPGPCertsToServerCommand
    • ExportPaperKeyCommand
    • GenRevokeCommand
    • ImportPaperKeyCommand
    • LearnCardKeysCommand
    • RefreshOpenPGPCertsCommand
    • RefreshX509CertsCommand

gpg always used UTF-8 the option to enable this is the default for more than a decade.

Oh well, in case you mean the diagnostic output things are different. gpg uses the code page as returned by GetConsoleOutputCP becuase we are a console program. Qt might assume that GetACP is used (as for GUis and thus we get a wrong codepage. You may try to run "chcp 65001" before starrting kleopatra or figure out how to convince Qt to set the codepage to 65001 (utf-8)

I created a self-signed X.509 test certficate with subject CN=日本国,C=JP (Nihon-koku/Nippon-koku; formal name of Japan).

Import the certificate and click on More Details in the Certificate Details window to reproduce the problem. For me the subject is displayed as

Subject: CN=µùѵ£¼Õø¢,C=JP

Test certificate:

In Windows PowerShell, I get the following output:

The active codepage is 65001.

Copying the output and pasting it in Editor (notepad?), it is displayed correctly. So maybe PowerShell just lacks a font to display Kanji characters.

Debug output in stringFromGpgOutput gives me

[1352] org.kde.pim.libkleo: stringFromGpgOutput GetConsoleOutputCP() returned 0
[1352] org.kde.pim.libkleo: stringFromGpgOutput GetOEMCP() returned 850
[1352] org.kde.pim.libkleo: stringFromGpgOutput GetACP() returned 1252

Kleopatra uses the first one that's not 0, i.e. 850, which is obviously a bad choice. The latin-*-variant 1252 won't help either.

stringFromGpgOutput actually received the following 8-bit data:

[1352] org.kde.pim.libkleo: stringFromGpgOutput ba: "      Subject: CN=\xE6\x97\xA5\xE6\x9C\xAC\xE5\x9B\xBD,C=JP"

This looks very much like UTF-8 (i.e. codepage 65001).

Since GetConsoleOutputCP() returns 0 for Kleopatra we probably need to ask gpg what codepage to use.

Should be fixed. Tested as described in the above comment T5960#165845.

Note that this requires a version of gpgconf that supports the --show-codepages option.

ikloecker changed the task status from Open to Testing.Dec 8 2022, 11:32 AM
ikloecker removed ikloecker as the assignee of this task.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

Here is an other instance with broken encoding (on 3.1.27.0-beta44):

In T5960#168905, @ebo wrote:

Here is an other instance with broken encoding (on 3.1.27.0-beta44):

Technically, this is a completely different problem because in this case the text is not read from stdout/stderr of a different process but it is returned by GnuPG's own gettext implementation (on Windows). We may have to call gettext_use_utf8(1) somewhere. Otherwise, GnuPG's gettext seems to convert the texts to local encoding, but Kleopatra always assumes UTF-8. This should affect all texts containing non-ASCII.

@werner Can you confirm that we have to call gettext_use_utf8(1) in Kleopatra to make GnuPG's gettext return UTF-8 on Windows?

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

The texts for GnuPG error codes should now be displayed correctly.