@gniibe I saw that you didn't understand what I meant by "dirmngr stops working properly" in E663.
Have a look at this post in Archlinux forum.

Yes, I forgot to include the full build log, I'm attaching it here. I've seen this in OpenSUSE Tumbleweed; the compiler is gcc10; and I can see this on any architecture. The test fails when building against gpg-2.2.21 but not with previous versions.

Pretty please write a useful bug report; we need information on versions, OSes, compilers, any special environment, and all the steps you did to get the build failure. The configure run already prints a lot of useful information; you may want to extract them or provide a complete build log.

Creating is not that useful - we prefer modern curves anyway.

I think that retrieving a parameter in compressed format is all what we need as per API.

(3) _gcry_ecc_os2ec in libgcrypt/cipher/ecc-misc.c should be modified to support parsing compressed representation.

While I see that it's not the matter of actual use case (but how gpg can be immune to fuzzing), code clean up would be good here.

Thanks for the patch.
I see your point in T4975: undefined-shift in block_filter.
You are right that we have a problem of possible overflow (which could be kicked by fuzzing) here.
(The actual impact would be small, though).

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

Because a few minutes don't matter. If you have the time to figure the reason out, please go ahead. It might be that we take the timestamp in the addkey case earlier and only set the expiration date after the key has been created.

gpg has code to make sure that a new key is at least one second newer than the previous generated.

The default for GnuPG 2.2 is still 2048 (Debian changed that in their distributed version). The reason for this is that we don't want to generate such keys but move on to Curve25519 for the new defaults.

Duplicate - see T4702 instead

I won't fix it. In fact it can't anyway be completely fixed because gpg has code to make sure that a new key is at least one second newer than the previous generated.

It has now been implemented for all types of symmetric encryption (not just -cs). To go into 2.2.21

The first, I guess. The problem is that you are technical capable of _decryption_ but gpg does not allow this because for some reasons the key is arbitrary limited to signing. A warning message should be printed in thus a case but decryption should succeed.

Or this (don't allow anon keys for different usage):

diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c
index 14cbdbb0f..b8d4059cd 100644
--- a/g10/pubkey-enc.c
+++ b/g10/pubkey-enc.c
@@ -91,9 +91,6 @@ get_session_key (ctrl_t ctrl, struct pubkey_enc_list *list, DEK *dek)
       if (err)
         break;

Do you mean something like this?

Fixed in rM1b840a151ad7: python: Fix how to generate documentation..

It's in master (to be gnupg 2.3).
Enjoy.

The qualitybar has now been removed from 2.2 and master.