Please wait investigating it, a downgrade of the *kernel* from 6.8.2 to 6.8.1 helped. It seemed the USB communication got broken with 6.8.2. I am investigating

I rebooted, edited the scdaemon.conf to match the above, and tried gpg --edit-card with the yubikey plugged in. It resulted in the same output:

For the reference, for now i just did the dummy install in the Fedora spec file:

Please use

Tobias, if you find some time, can you please see how this can be done.

Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?

The certificates from the same test smart card work in Version 3.2.2.231170 (Gpg4win-4.3.1), too, but there all certificates are shown, that is one more than in the VSD version. Seems gpg2.4 can handle certificates which 2.2 does not accept. But that is nothing to complain about.

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.

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.

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

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.

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.

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.

strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.

By adding "-Wl,-t" to the arguments g++ reported:

Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)

It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).

Thanks, that patch works for me.

And we should also use timestamps for each signed file so that we don't need to re-sign all of them over and over during build process tweaking.

Fixed in master.

The reset was due to running gpg-connect-agent reset /bye. I am currently testing something elese will get back as soon as I can turn back to 2.4

Note that this has also been ported to 2.4 and 2.2 and tested by looking at the status lines.

There are two locks here; (1) rw_lock for card_top (list of cards) access and (2) individual card lock.
It looks for me that:

• don't know how/what the thread 7208.2 does
• the thread 7208.3: KEYINFO, then PKSIGN (gets read lock for card_top, then, individual card lock)
• the thread 7208.4: SERIALNO --all (and wait for write lock for card_top)

Thanks for reporting this. Returning error codes to upper layers is not always easy because the original logic is that we have a global error counter to decide whether an operation succeeded. My fix to check the error code before emitting the DECRYPTION_OKAY status,

handle_plaintext gets data returned by iobuf_read, and does not check the error status of the iobuf object.

But only if you can figure out in a transaction or locked sytate whether the card needs a verify. Otherwise we have a race between changing the PIN and verifying a PIN.

This rejection could be relaxed.

needs to be fixed soon. But we don't have a tag for Gpg4win 5 or whatever we call a kf6 based gpg4win.

It could have been discussed whether this makes sense. However, we can't change it anymore because it would change the behaviour. Consider a cron job which looks into a directory with keyids and imports them from a keyserver. It is totally fine if the script returns success if no keys are available.

There is no way to recover it?

See T7034

Sorry, this is not a help line but a bug tracker. If you lost or forgot your password you are screwed up.

I have also not found a straightforward way to correct a cross-signature that was made with a weak digest algorithm using GnuPG.

I've sent you an email about it. It might have html elements due to markdown-here.

Sorry, for not following up earlier. Can you please do me a favor and run the last tests again, this time adding -v and --debug 1 to the invocation? Feel free to forward the output to my private address is that is easier (wk at gnupg.org).

See also: https://gnupg.org/blog/20240125-smartcard-backup-key.html

How to test:

Thank you!

Applied to both (master and 1.10 branch).