External projects should have been using pkgconfig since a long time. The *-config scripts are for systems which lack pkgconfig.

In T6305#165907, @ebo wrote:

With GnuPG VSD 3.1.25 the Certify action is not disabled for me. Neither on Windows nor on Linux system.

I cannot find the commit which fixes this issue.

With GnuPG VSD 3.1.25 the Certify action is not disabled for me. Neither on Windows nor on Linux system.

How did you manage to certify an expired key? For me the Certify action is always disabled for an expired key or user ID.

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

Thank you for your report.
Please look T6204.
Closed as duplicate.

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?