@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:

This is the minimized test case.

Having a fallback in Kleopatra makes sense because very old HKP keyservers don't return the fingerprint and LDAP keyservers not using the modernized schema do neither.

Please read also the report T5442 which is basically the same.

Thanks for the well written report. We had another already, and thus I merged it into T5415.