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

You are right. The problem is that in a development version we use an envvar to locate the programs, so there is usually no problem because the software has already been installed and the final test doesn't catch this. We should add a version check to all components to catch such problems.

Given that we don't yet support TPM for Windows you should go ahead and apply this patch. tpm should also be removed from the list of components.

Thanks, that was right in time for this weeks 2.3.1.

aheinecke: I agree, we should not port everything back just because we could do that.

Has been released with 2.3.0 and we better open a new task if problems show up with v5 key. I am pretty sure that there will be a few v5 key problems after they get in real use.

This has been released with 2.3.0 and no relevant problems have reported in the last two weeks, thus closing.

Thank you. Merged and pushed.

@werner No problem. Just go ahead.

In T5393#145158, @werner wrote:

Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.

Regarding the identical branches thing: This is on purpose. The function works closely together with another one which will then BUG() out. @Jakuje: If you know some meta comment to attribute this, please let me know.

@gniibe: If you don't mind I would like to steal task this from you. I have noticed a few things which could get a little code refresh in addition to the fixes.

There is couple of issues that I did not want to propose a patch for, but might require some attention:

Error: IDENTICAL_BRANCHES (CWE-398): [#def28] [important]
gnupg-2.3.0/common/tlv-builder.c:353: identical_branches: The same code is executed regardless of whether "tag < 31" is true, because the 'then' and 'else' branches are identical. Should one of the branches be modified, or the entire 'if' statement replaced?
#  351|     (void)constructed;  /* Not used, but passed for uniformity of such calls.  */
#  352|   
#  353|->   if (tag < 0x1f)
#  354|       {
#  355|         buflen++;

There are also couple of reports about the function default_homedir(), which is supposed to return const char * but in reality, it sometimes allocates memory while callers do not expect it so they do not free:

Error: RESOURCE_LEAK (CWE-772): [#def11]
gnupg-2.2.27/common/homedir.c:477: alloc_fn: Storage is returned from allocation function "default_homedir".
gnupg-2.2.27/common/homedir.c:477: var_assign: Assigning: "newdir" = storage returned from "default_homedir()".
gnupg-2.2.27/common/homedir.c:488: noescape: Resource "newdir" is not freed or pointed-to in "make_absfilename".
gnupg-2.2.27/common/homedir.c:490: leaked_storage: Returning without freeing "newdir" leaks the storage that it points to.
#  488|     the_gnupg_homedir = make_absfilename (newdir, NULL);;
#  489|     xfree (tmp);
#  490|-> }
#  491|   
#  492|

Thank you. The initial run was against olderer version of gnupg (and had one issue in g10/keyedit.c -- see the new patch with fixup). Now I ran it against the version 2.3 and there are couple of more issues to be fixed (rebased on top of already applied changes and the previous commits).

Thank you.

Thank you. Applied and pushed.

(FYI I did not notice any other errors with 2.3 so far)