Attached is an even worse PKCS7 blob, that should be validatable given reliance on ca.rsa.crt, but it will be rejected by gpgsm because the PKCS#7 bundle includes ca.rsa.cross2.crt in it.

OK, i have replicated this successfully with no ed25519 involved. here's the new intermediate cert:

Which NIST test suite are you referring to? It might not cover certificate pathfinding in the face of multiple cross-signed authorities.

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

I do not have the time to analyse this in the context of our approved versions and to compare it to the NIST test suite. We also do not yet have support for ed25519 certificates.

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

So what do you think is the threat here?

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.

My concern is not a disloyal administrator, so I disagree with that priority.

CVE-2021-33560

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.

thanks!

The error codes we use are a combination of code and location.

Could make --multifile work on windows 10, documenting the workaround here.

I give this a low priority because all those infos are easily retrievable from config files.

Thank you for your report.

Let me rephrase from a viewpoint of mine (an implementer).

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.

Current look without public keys:

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.

The paper describes another problem: interoperability (or interpretation) of "ElGamal encryption", and its impact.

This is another test case for GNU C library's strncmp: