It's not a different kind of data. In both cases it's the serial number of the smart card either in human readable form (often as printed on the smart card/USB token) or in "untranslated" raw form. It's a bit like short Git hash vs. full Git hash.

what about the case that the key has a mail address? Is WKD still checked?

works for latest VSD Beta, too (VS-Desktop-3.1.92.39-Beta)

looking at my private key directory, the data for the display serial number seems to not always be there FWIW.

While reviewing the changes I had some doubt about some of the columns.

FYI as a VSD customer you have access to support. Please check Help-> about Kleopatra for the infos,

In a current version I see this at least if I do not quit Kleopatra completely and restart to another screen setting. Further testing at the moment is not warranted, as there will be changes to the columns handling with the switch to Qt6. (T6924)

Btw compare the Kleopatra versions in Gpg4win and your VSD Version. They should mostly be identical with VSD maybe lagging a bit behind, Or your emplayer has not updated VSD. Many don't

We're waiting for a RNP v0.17.1 release which intends to tolerate this mode.
https://github.com/rnpgp/rnp/issues/2198
https://github.com/rnpgp/rnp/pull/2190

This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198

After much investigation and debugging it turned out the problem really was that KOrganizer was hiding declined and unanswered invitations. Fixed already in master and 24.02.

Btw we should probably add TB in our QA environment to check for such things. Esp. with future changes in GnuPG we should try to use TB and maybe a bounycastle MUA (Greernshield?) to avoid creating accidental incompatibilities.

I cannot think of any of our products where you cannot chose the signing key.

From your description it is not clear what you did exactly.

To reproduce:

• Send a mail to yourself
• add an attachment
• select encrypt

I assume you mean the information shown in the subkeys window int the column "Strength"?

Given the situation where GnuPG works well with existing OpenPGP card implementations, what we should do here is, perhaps:

There are multiple problems described in your report. Let us handle one by one.

Thank you for your quick testing.

Works for me using the latest vsd beta (3.1.92.39)

I've reported the success to MacPorts. My test was performed on only one platform, Mac OS X 10.4.11 or "Tiger". Since there exists a problem with building recent version of GPGME testing on Mac OS X 10.5.8 or "Leopard" will have to wait a few days…

With the unified patch all works fine (again), even the test target succeeds!

I think last time we talked about some generic solution for this. And ended up trying to research if we could add this in the end after linking is done to avoid having to patch/add an RC file for every library like GnuPG. Kleopatra and GpgOL already has one as you can see in windows with right click / properties and then details. Maybe we need to change the values there.

Performing the patch manually the "port" (package) built and installed. Starting then gpg-agent worked too, killing it (with gpgconf) worked as well.

The patches looks too large to merge (than actually needed), and not enough/clean like not having detection of the system.

I am still not sure why I noticed the double signing but with the new stamp feature we have an effective way to avoid long delays due to authenticode signing. Some gmake macro guru might want to look at gpg4win.mk.in to get rid of the duplicate rule ignore messages.