Please keep also in mind that the OpenPGP card specification has always and is still developed along with GnuPG . Thus if there are any uncertainties in the specification GnuPG's way of handling thing is the way to go. If there is a way to chnage things without risking any breakage we can of course fix that. In all other cases we need to continue wit the current way. For larger changes in the spec we can of course cleanup stuff - Achim is currently reworking on a revision.

Thanks. I wonder if we should inform distros about this?

Please keep in mind, that it is not only about GnuPG and the OpenPGP card, but also between GnuPG and other PGP applications. I'm not really sure what the recent commit is doing, if it only affect the reading or also the writing of the data. But IMHO GnuPG should stick to the standard also if writing the KDF DO data because eventually, it will be used for authentication with the card.

Fixed in 24.02.2

Sure WKD is still checked if the conditions for an update via WKD are fulfilled.

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.