For the particular issue reopened for GnuPG 2.2.41 is fixed in GnuPG 2.2.42.
Please note that we can't fix the cause itself, the hardware problem.

Bug is in 2.2, too.

It would be good to apply this to 2.2, so adding "backport" tag.

Fixed in rG2be53b214d1c: tools: Fix argparse table of gpgconf..
It would be good to apply this to 2.2, so, adding "backport" tag.

Applied a patch from 2.4/master to 2.2 for SEGV when card gives bogus data. rG600e69b46149: scd:openpgp: Fix a segv for cards supporting unknown curves.

@desultory Thank you for your report.
Please open a new ticket for your problem. If you can, please show the result of https://dev.gnupg.org/T5963#157724

This is still an issue for me:

Yes, works now ( VS-Desktop-3.2.0.0-beta from today):

In T5903#176176, @ikloecker wrote:

Please submit a separate feature request for this.

In T5903#176175, @uwi wrote:

I'm late on the train, but (talking about Kleopatra) there is a menu entry to refresh all keys, but I miss a RMB (right mouse button) context menu for the list of certificates to refresh just the current one (much similar like the feature requested, but "one UI level higher").

I'm late on the train, but (talking about Kleopatra) there is a menu entry to refresh all keys, but I miss a RMB (right mouse button) context menu for the list of certificates to refresh just the current one (much similar like the feature requested, but "one UI level higher").

works, tested with VS-Desktop-3.2.0.0-beta214.
For the remaining issue with a certain date range see T6736

Why do you think that no WKD lookup occurs for keys of unknown origin? gpg and therefore Kleopatra doesn't report any import results for certificates that are not published via WKD when doing --locate-external-keys --auto-key-locate clear,wkd.

Tested at first with GnuPG-VS-Desktop-3.2.0.0-beta178 from 2023-08-29

Optionally, (configurable on the Directory Services page) Kleopatra now queries WKDs for all user IDs when updating an OpenPGP certificate.

We decided to keep the current behavior as default (privacy by default), but to add an option to enable WKD lookups for all user IDs.

In T5903#174528, @ikloecker wrote:

OpenPGP keys are now also updated via WKD, but only for user IDs which were originally retrieved via WKD (i.e. which have origin WKD).

The changes have been backported to VSD. Note that they require today's changes in gpgme (just after the release of gpgme 1.22.0).

OpenPGP keys are now also updated via WKD, but only for user IDs which were originally retrieved via WKD (i.e. which have origin WKD).

Backport to VSD, as leaving out WKD is a bug.

Yes I think that can be safely backported to gpg4win/23.07

Yes I think that can be safely backported to gpg4win/23.07

Applied to 2.4.

This has long been implemented due to the backport of the P12 parser and the recent rewrite of it.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Done (STABLE-BRANCH-2-2.40 for now)

Let me describe the changes recorded in this task.

Shall we really backport this to 2.2 given that ECC for S/MIME is in most cases a smartcard thing?

In regards to this issue, we were also notified that the MD API using gcry_md_setkey() can be used to calculate HMACs and it does not have the needed input key length limitation. From the discussion here I read that we would like to keep the internal usage still available so my proposal would be to to add similar check as in gcry_mac_setkey() into the above function. Together with the revert, it is available in the following merge request:

In T6039#164435, @gniibe wrote:

I read the document (SP 800-131Ar2) again. I think that it would be irrelevant for PKDF2, because it's password KDF, not deriving additional keys from a Cryptographic Key.

I read the document (SP 800-131Ar2) again. I think that it would be irrelevant for PKDF2, because it's password KDF, not deriving additional keys from a Cryptographic Key.

Needs to be forward ported to master

exact v.2.3.8 is expected, generally I don't import Key on yubico I generate them directly from yubico itself in order to have the private Key created directly on yubico and not exportable.

Hi! I would like to add my experience about this issue.

what's new for a possible gnupg 2.3.8 or gpg4win 4.0.4 release?

Should go into 1.10 too

@gniibe Perfect, I got the update during the night actually. Thanks a lot for your work 🙏 .

For the firmware 5.4.3, I confirmed that it works well with the changes:
https://dev.gnupg.org/T6070#160150

Hi lovely people,

I have exactly this problem with yubikey here,
since i upgraded to gpg4win version 4.0.3 which contains gnupg 2.3.7 i get the same error as openpgp key not recognized.

@tigernero 2.3.8 is not yet released. Pretty sure gpg4win is a separate project, presumably you'll see a changelog entry here (as there is bumping to 2.3.7 in the latest 4.0.3) when it's in:
https://www.gpg4win.org/change-history.html
https://www.gpg4win.org/support.html

I can't find a url to download gnupg 2.3.8 for windows is it possible to know when gpg4win v.4.0.4 is out which fixes this bug? because currently on windows systems I am stuck using yubikey.

I just confirmed that firmware 5.4.3 works fine with the changes (to be 2.2.37 and 2.3.8).

New release of libassuan is expected to make sure it's cleared off.

It's in 2.3.7 and 2.2.36.

Does Yubico furnish you with devices for test...

Thanks @gniibe. Does Yubico furnish you with devices for test, or did you have to order that at your own/the project's expense?

It will be in 1.10.2.

It will be in 1.10.2.