You better wipe ecc_d_padded or use xtrymalloc_secure.

Put

extern char **environ;

after the the include directives.

Go ahead (but w/o the /*if (keytime*)*/ line ;-)

The problem is that posix_spawn is not portable enough for libgcrypt. It is really time that we move the spawn functions from gnupg to gpgrt so that we can use them also in Libgcrypt.

The error comes form using READKEY which is processed by gpg-agent. At this time the agent does not yet know the stub key and thus returns ENOENT. At the places before we used "SCD READKEY" which works directly with scdameon and does not need a stub file. We need to review the new(?) way of creating stub files, describe that and then fix this by either making sure tha the stub key is created first or that we use SCD READKEY there too.

Why the hell do they that? The standard compiler on a system is called cc which may translated to whatever the system installs for it. gcc is a specific implementation with certain properties. Di you try CC=clang to override this?

You say that you build using clang but the log shows that you invoke gcc.

No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.

This has been fixed for Unix on 2.2 and 2.3. The command line fix for Windows is a larger thing already tracked by T4398.

We changed the fallback to utf-8 in 2.2 and 2.3 and thus this bug can be closed. On Windows there is still the problem with the command line. However, this is better tracked with T5038 and its related tasks.

Regarding a backport I think that I will eventually backport all app-*c to stable by source copying them. We have a quite stable internal API and thus it is easier to keep at least the card specific code in sync. I did some local work in this directory some time ago.

Recall that each user has their own keys and configuration. This seems to be a general question on how to use GpgOL. Please use the help resources listed at gpg4win.org instead of this bug tracker.

You are right, the new 3.4 cards support brainpool curves in addition to the nist curves.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

Released on 2020-11-18

Note that if you run into problems with a smartcard you should run "gpg --card-status" once. GUI frontends usually do that and this is the reason why this regression was not detected. Will be fixed in 2.2.25 (T5140).

Removing 2.2 tag because it has been fixed in one of the last releases.

Its done for 2.2 thus changing the tag.

As @dkg noted T4592 is a duplicate of this and given that we have a mitigation in place we can also close this (older) bug.

Thanks.

Before step 2.d you should stop gpg-agent and other daemon

This was fixed in 2.2.24 with commit rG7f765a98fd662

If you want to debug this, I suggest to use a logging socket. Put into all gpg-agent.conf files these lines:

I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).

Right, our installation really needs an update. It is not gnupg.org mail but just the mails from phabricator - which unfortunately does not use our standard mail system

Urgs, that was my fault.

We had some card related regressions in 2.2.23. I would appreciate if you could first test again with 2.2.24 which was released yesterday.

I am sorry, but this is not a help desk but a bug tracker. See https://gpg4win.org or https://gnupg.org to find out which community support is available.