AFAIK, Stephan evaluated it only for x86, let me ask him ...

We already have the option --sender which does what @mgorny requests but only in the TOFU case. I need to revisit the system to see whether we can extend it to WoT and direct key signatures.

Done.

Let's wait with this until we ship a libgpgrt. I am not sure what the best way to migrate to another library name. By current idea is start with some release installing two libraries using the two names but with identical code. Some releases later we could require a configure option to install libgpg-error in addition to libgpgrt.

Thanks. I bumped it up to be in sync with GnuPG 2.2. It also does not make sense to require a Libgcrypt which has reached end-of-life; Thus we now need 1.8.

I bumped up the requirement to 1.25 because we also use error codes defined there. To be on the safe side with older distros I defined the missing error code instead of requiring 1.27.

Thanks for the report.
I now describe the shortcuts as development and 2.2 stable branch.

The problem is with the code for T3656

Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.

no prob

@Angel: The mail server log showed 0 bytes for the affected messages.

While triaging issues this looks to me more like a support case. And not an issue of the software itself. So I'm closing this issue.

Uh, I just noticed that this issue is from dec. 2019 I am unsure why I overlooked this and only noticed it in my regular tracker check today.

@JJworx Thanks for the suggestion / feature request.

As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.

Change of gpg-agent for ECC-SOS

I agree.
It (only) fixed a regression where a user can specify a fingerprint to select a card (rarely used feature in the scdaemon protocol).

Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)

Although this is a standard behaviour for Unix tools, you are right that it makes sense to tell the user about the problems. And well, the version info should not appear either.

FYIL This is delayed because there are some dependencies to internals of gnupg.

Merged. Thanks.

Ok. However, I don't think that the fingerprint is really important. We can compute it anyway as long as we have the creation date. The keygrip is meanwhile more important but that is also easy to compute.

Perhaps, no change would be required.
My major concern is that: the data object for fingerprints C5 and C6 were defined as fixed-size 60-byte objects (and actually _is_ defined still in the current specification of 3.4), but it's 80-byte (newer Yubikey), which might cause problem(s).

Is there a blogpost or similar where the use of several smartcards following this improvement is explained to n00bs like me? :) For now all I find is this thread and some SE answers saying it does not work yet (https://security.stackexchange.com/questions/154702/gpg-encryption-subkey-on-multiple-smart-cards-issue) . If somebody could post a new answer on SE / write a small blog post or similar that would be great. Useful would be to have 1) from which versions and over is that available 2) how this works / how to use.

Why do you think that we need to care about the attestation key? Where possible I take in new code in account that we will have more OpenPGP keys, but right now I don't think that is makes sense to replace our data structures for that the 3 element arrays we currently use are okay for the 3 standard keys. We can latter see how to replace them. At one place I already introduced something new:

Here is a dump of my token (Yubikey 5.2.6). I used the new apdu command of gpg-card along with "undump | dumpasn1 -", which saves quite some time: