AFAIU, gpgrt-config works well now for the multilib MinGW target.

I*m sorry, but I haven't found a way to determine what version of gnupg I am running. Just in case things got confused, I am not the thread opener, my version of gnupg is not whats been stated in the opening post but rather whatever is current on Arch Linux: Linux 6.0.11-arch1-1
I ran gpgsm --version though which returns this:
gpgsm (GnuPG) 2.2.40

Please update to a recent gnupg versions. 2.3.3 or if you really need the LTS version use 2.2.40. Instead of using a log you can import on the command line:

After years of using S/MIME I ran into a strange situation importing my new S/MIME certs to Kleopatra yesterday which ultimately led me to this thread.
My case is slightly different because my original passwords were short (2w7g9r1e and 2y8m7i5t), but it feels related so I thought I'd share nevertheless.

I also reproduced this bug. I am using a PIV configured YubiKey 5C NFC for GNOME Smartcard login, which uses pam_pkcs11, and pam_pkcs11 uses opensc to read it via pcscd.

The current WKD/WKS draft offers no direct guidance to WKD clients about the type of filtering they should do.

The problem with expired keys may still happen for GpgSignKeyEditInteractor, but Kleopatra doesn't allow certifying expired keys or user IDs. Therefore, I don't look into this.

OK I can confirm that with ae9258fb and f1802682 commits I was ble to update my rpm packages to 1.18.0.

I've hit that issu on downloading two times so I think that there are two nodes behind LB :P

Just checked those two commits and I see in autoconf output:

checking for gpg-error-config... no
checking for gpgrt-config... /usr/bin/gpgrt-config
configure: Use gpgrt-config with /usr/lib64 as gpg-error-config
checking for GPG Error - version >= 1.36... yes (1.46-unknown)
configure: Use gpgrt-config as libassuan-config
checking for LIBASSUAN - version >= 2.4.2... yes (2.5.5-unknown)
checking LIBASSUAN API version... okay

So looks like there is more use of *-config scripts and those detections takes longer time so it would be good to move that as well to pkgconfig.

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 !