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.

Last week:

• Worked on CardOS support. Basically working now with a one bug left. I have no specs except for a way to look into a 15 years old 4.3 manual - we have 5.0, though.

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.

Last week:

• Bug fixing
• Infrastructure

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).

If you run into build problems on OpenBSD for gpg-wks-server, see T4886 for a required minor fix.

No info received; either really malware downloaded from a fraudster site without proper checking on bare coincidence with other updates.

@sarman: Your question is actually a support question and not a bug report. Please read the documentation, use the public help channels (so that other can also learn from the issue), or get in touch with a commercial support provider.

From where did you downloaded it? Did it show a valid issuer for the software (Intevation GmbH)?