Thanks for reporting; the code is really new and not yet fully tested.

Data (ie.e CMS) signatures do now also work.

I think I fixed a memory leak on error but no other changes for old code except that the array to old the args now takes void* and not gcry_mpi_t - which does not make a difference.

There are no betas; either you apply the patch mentioned above ( rG2f08a4f25df7) to a stock 2.2.20 or you build from the Git repo (STABLE-BRANCH-2-2, see https://gnupg.org/download/git.html).

Okay certificate and CRL checking does now work with rsaPSS. Need to work on data signatures and check the compliance modes.

I started to work on it so that I can actually use the certificates on my new D-Trust card. This will be a verify-only implementation.

FWIW, the code was written by the author of the specs and he note in his original patch (rGe0972d3d96) :

That smells very much like an old and insecure version 3 key. We don't allow them anymore - use gpg 1 to decrypt old material but never use that key to sign stuff or give it to others to encrypt to you. It is just too weak.

Please explain what your problems is. Setting arbitrary debug flags is not helpful for your or us.

EdDSA is sign only - how do you want to encrypt to such a key? Did you mean cv25519 and ECDH?

I also don't think that key size obfuscation is useful, after all the preferences of the key demand a certain key size.

Clever idea.

Please stop this and use the mailing list for such ramblings. Usually only one developer reads a bug report and thus you can't participate from the experience of others - use mailing lists - please.

See my comments on the other bugs you posted today.

Please see my other comments; we need proper bug reports and not just arbitrary snippets.

That are all development versions and they may require the latest changes from the repo of other libraries.

Please write proper bug reports and do not just post snippets from some arbitrary build process. In addition master is non-released software and thus it is in general better to ask at gcrypt-devel@gnupg.org for help.

Sorry, if you use your own copy of GnuPG on GitHub, it is all up to you. We do not use Github.

Applied the fix also to master with a comment to ebentually replace it with es_fopenmem.

Done; will go into 2.2.21 (T4897).

Thanks.

The problem was the comment field which was not expected in an rsa key. However ist makes sense to allow additional fields and thus I pushed a change to Libksba.

No, we always stated that the user id is a mandatory part of OpenPGP keyblocks and that non-compliant keyblocks are rejected. The only exception we made are for revocation signatures where we allow a standalone packet. That exception is done to allow typing in a printed out revocation signature.

With OpenPGP we made user ids mandatory to avoid problems we had with PGP2. I see no reason to revert this.

I recall that I talked with Stephan about it but things got lost.

This is an important information to know because it can help to avoid bug reports.

Please use the mailing list for help on generating keys. I would also suggest to use GnuPG master for such experiments.

FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).