For GCC 11, modified version of struct arg_and_data_s has an issue for x86_64.

Oh yes, I was blind.

Here is the place:
https://dev.gnupg.org/source/gnupg/browse/master/g10/pubkey-enc.c$151

A cursory look doesn't show me where list->result is set to something else than -1. Can you give me a hint?

In GnuPG 2.3, the procedure of decryption has been changed;
It now collects all ENC_TO packet, keeping it to ->PKENC_LIST field, and then process ENCRYPTED packet with the list.

For the use case of struct arg_and_data_s in gpgme, which may allocate zero-sized ARG[], it seems that GCC 11 interprets it as an invalid use.

In T5436#148656, @cnp1234 wrote:

I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

Based on the info about this being caused by the added support of PIV, I poked around on the docs at https://gnupg.org/documentation/manuals/gnupg/gpg_002dcard.html and noticed the disable-application stuff. I added "disable-application piv" to ~/.gnupg/scdaemon.conf and the behavior went back to pin caching working as before. Since I don't use PIV, this is an acceptable workaround for me.

bug has been closed as Wontfix [..] I see no reason to continue the discussion in the bugtracker.

This bug has been closed as Wontfix more than a year ago. I see no reason to continue the discussion in the bugtracker.

I share your concerns about centralization of keyserver infrastructure. Rejecting this security fix doesn't help keep keyservers decentralized, though.

It is now over 10 months that the proponents of these additions have not followed up on the discussion.

There is no point in questioning whether a couple of words change racism or any other human problems of these days. It will not.

Sorry, this is not acceptable to me. <rant>You don't change racism by avoid words which are may be connected to racism. Master is a term used for example to indicate that a person is proficient in her profession. Slave is (in theory) a historic term to describe, well slaves. That is humans who are non-free and are not allowed to control their lives - like the majority of humans these days - they are just called different and the methods of suppression are different than in the past. In fact a Roman slave (but not a medieval bondsman) had well defined and esteemed rights not something the majority of US citizen with a dark skin has in practice. Term abolished, racism abolished, works as good as freeing the US slaves in the 1856, the 1960, or still today. It did not work. Mr. Kings hope has not yet realized itself and is now maybe farther away than we all had hoped in the second half of the last century. Don't cover facts by changing words used in a very different context.</rant>

The original idea with the DNS code was just to source copy it but it turned out that we need to maintain it in GnuPG. Thus adding support for SHA256 makes sense to keep the code current in case we ever need to use it.

For the Data Object of serial number, what I read is this code: https://github.com/Yubico/yubikey-manager

FWIW: Actually the old code assumed that the s/n is at least 4 bytes. IIRC, I once checked the source of the Yubico tools to get this info.

The device with serial number 10000003, it is represented as three bytes: 00989683

In 2.3, the logic to identify Yubikey has been changed (to support PIV application).

Here, we use keygrip search: https://dev.gnupg.org/source/gnupg/browse/master/g10/skclist.c$429

There is also the issue that options flagged as ignore or forced in the global config file won't have an effect either. But indeed we could mark them as non-change.

Because an existing setting in gpg.conf overrides the keyserver set in dirmngr.conf

why not use gpgconf with the dirmngr component to set the keyserver option there?

Thanks. I push the fix of yours.

@werner @ikloecker Any more thoughts / updates on this?

You should anyway use --quick-gen-key.

Setting a curve type (which shouldn't be necessary) like "Curve-Type: ed25519" doesn't help either. While this makes the check in gpg pass, the gpg-agent process re-checks the parameter set and rejects it with the same error message.

Thank you. I checked what was missing and all looks good. But do not understand why the last gpgsplit xfree was not applied. We are leaving a block where this variable is dynamically allocated so even without error we need to free it.

The first two patch sets are now applied with the exception of
the gpgsplit fix; I did not applied that patch to add a free() in case of write errors.

Ha! This would have affected Kleopatra if we followed werners suggestion to use default. But in Kleo I decided that I needed to show my users what the default is so we do not use default in this case.

In T5393#145098, @gniibe wrote:

Please note that *_error-from_syserror accesses system's errno which may be cleared by xfree.

Possibly, it keeps running at calibrate_s2k_count, for some reason.

I was wrong.

In T5436#146148, @ikloecker wrote:

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

Just got around to testing this on Linux, and I can confirm the same behavior: decryption PIN caching works on 2.2 and doesn't work on 2.3.

@znull You can also fix the detection issue by building with ./configure --disable-ccid-driver, in which case you won't need the disable-ccid setting anymore.

@ikloecker Sorry for not being clear, I was not aware different operations have different behaviors in regard to entering / caching the PIN.

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

I just wanted to chime in that I've had exactly the same experience as @lbogdan: gnupg 2.3 stopped recognizing my yubikey entirely on MacOS until the T5415 workaround (disable-ccid). After that, pin caching was broken until I applied his patch to call-scd.c:548, which makes it work as before. Without these two changes the experience with gnupg 2.3 is degraded relative to 2.2.

So I did a bit more reading on smartcard PIN caching, and took a better look at the debug logging of gnupg 2.2, and learned that, indeed, the PIN is cached by the card and not by any one gnupg component.

Yes, I already linked to T5415, but that breaks YubiKey completely, and I fixed it with disable-ccid.

The pincache is actually not what you think it is. It is only used to allow switching between different application on a Yubikey which reqieres a new VERIFY command after switching back to the first application the card. What you feel as caching is the state of the card, which usually keeps its verification state until the card is powered down.

FWIW, we can and should run our test suite under valgrind from time to time

Sorry, it's my fault.
Fixed in rGac731dbbbd21: gpg: Fix allocation for EXTRAHASH..

Applied in rG32baa9acfb15: scd: Serialize READER_TABLE access for PC/SC..

Please note that we don't use lock in apdu_dev_list_start/finish any more.
Use of lock is narrowed, only within apdu_open_reader function.

We should add a comment at the caller side, that this takes a lock in apdu.c.

Make the lock holding narrower, and it allows no exposing reader_table_lock.

Exposing reader_table_lock would be better.
I found a dead-lock condition when apdu_close_reader is called during apdu_dev_list_start/finish.

And if the coding style of hiding mutex_lock/mutex_unlock inside different functions matters, we can expose the mutex to its user.

Last commit will be:

The second commit is replacing a use case of close_pcsc_reader by clearing pcsc.rdrname and calling release_pcsc_context.
This makes the use of close_pcsc_reader to its original purpose only (== closing PC/SC reader as a method of close_reader).

OK. As I pointed out a commit having multiple things may make analysis difficult, I should have been careful.
So, let me fix the problem by multiple commits.

Keeping the lock over the call to the function does not look very robust to me. This is why I removed it. And since then PC/SC worked on Windows for me. Modulo this:
All these changes don't tackle the real problem that windows gets struck in a removed-card state.

Technical commentary on smartcard operation and/or Windows is going to be over my head, so I can't help (just in case you're looking for anything from me). But always happy to drive-test another build. (I've still had no issues, personally, with the build above.) I'll assume you don't need me unless you link another binary build to test or tag me. Thanks again, all.

The problem is accesses to reader_table by
(1) scanning reader(s) to open new one
(2) closing reader

I'm testing D531: Keep holding READER_LOCK_TABLE and make clear distinction among close/releasing_PCSC_context/nullify_rdrname, but I'm not sure about the impact on Windows.

The commit rGbb8e3996e44f: scd: Fix problem with reader list becoming empty. removed READER_TABLE_LOCK holding between apdu_dev_list_start and apdu_dev_list_finish, that opens possible stale resource access for CCID driver: reader_table[slot].ccid.handle

Thanks for testing. I hope to get 2.3.2 out in two weeks.

After upgrade:

Meanwhile we did some more tests on Windows and so you many want to try our betas at