In T5951#165848, @aheinecke wrote:

Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

I would suggest the following, if it is somehow possible. I think we have the API for this now that we can search for WKD keys without importing them. We should additionally check WKD, if the key from WKD has the same fingerprint, we update, if it has not, we show the user something like a search result. Give indication that a different key was found for these UserIDs and then let the user decide to import them?

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).

Ok. So after further discussion. It is good that you kept a WKDRefreshJob copy :)

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

In Windows PowerShell, I get the following output:

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

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)

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

stringFromGpgOutput is used by

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

I guess we can close this one.

works

I do not really understand why this is necessary. The problem is that /nonfatal conflicts with our msi creation as there is no such equivalent in the wix toolset language.

This overlaps with T5959: Kleopatra: Show key source in details widget if it is not unkown.

Another idea (based on above ideas): We add an optional column named "Valid For" and only list the usages that are currently possible. If the encryption subkey is expired, then the key will probably only be valid for signing and certifying. This should be easier to understand than my fancy color coding idea while still giving the user a hint what a certain certificate can be used for. I'd still abbreviate the usage to a single letter in English. Translators could still use more letters if a single letter would be ambiguous.

If you enter a wrong password in a window, the error message will only be given after you have answered all requests for the transport passwords.

A failed import is now reported immediately when the file was processed.

Thanks !

I think showing "partially certified" makes sense.

A real fix will be in the next gpgrt release

No. We now ignore expired key with --mirror, --create, and --install-key.

And what do we return if no keyserver is configured?

I would ideally like a result message like "Could not connect to keyserver ks.example.org" if the server is not reachable and
"the key has not changed on keyserver ks.example.org" or "the key could not be found on keyserver ks.example.org" if one of those is true.
At least the last two not if the key was found via wkd, obviously, in that case a similar message for wkd.

By the way, I don't know exactly what Werner means with

Works on the command line but needs more testing.

because at least on Linux gpg cannot import UTF-16LE-encoded armored certificates:

$ gpg --show-keys <test1-pub.utf16.asc 
gpg: [don't know]: partial length invalid for packet type 63
gpg: read_block: read error: Invalid packet
gpg: import from '[stdin]' failed: Invalid keyring

Kleopatra is now able to import certificates from UTF-16 (or UTF-32 or UTF-8-with-BOM) encoded text files.

Not so fun fact: If you enter tcp://1.2.3.4:10001 (literally) as value for gpg-agent's log file, then on save gpgconf calls
gpg-connect-agent --homedir /home/ingo/dev/g10/.gnupghomes/utf16 --no-autostart RELOADAGENT
which hangs (probably trying to connect to the not existing IP address or to the blocked port). This also makes Kleopatra hang.

Windows accepts forward slashes in all API calls. Users are sometimes confused by this but this is a documented feature for ages in the API.

@werner Full disclosure, it is possible to package gpg/gpgme within binary wheel for Python to support multiple platforms now. But, if there are no plans for that then I can use this for a namespace package instead.

But what about real Windows filenames?

I'm happy to hand over the PyPI package. Werner, what should I do with it?

The log file is intended to be an URL. Thus forward slash is fine.

The same problem will very likely occur with any file dialog opened by Kleopatra because file dialogs are always modal. It may not be nice that people can maneuver themselves in such a situation, but how likely is it that a normal user (and not just a good test engineer who is looking for such problems) will run into this problem.

Support for multiple smart cards has been vastly improved in the last few years. I will tentatively close this as resolved because it's very likely that the problems have been resolved.

Looks like Kleopatra is writing the filename with the system's preferred directory separator. If GnuPG on Windows works if filenames are written with Unix directory separators, e.g. c:/foo/bla or //server/foo/bla, to the config files, then we can certainly change this in Kleopatra.

Wild guess: Since creating a local certification seems to work, but creating an exportable certification fails, maybe the problem occurs when trying to promote an existing local certification to an exportable certification.

This has been fixed some time ago when the UI for generating OpenPGP keys was rewritten.