You should have read the release notes of 2.1 (first point). We can't keep a bug open because you had a wrong understanding of GnuPG properties. Sorry.

This bug has been closed as Wontfix more than a year ago. I see no reason to continue the discussion in the bugtracker.

Well, the keys are not generated but public keys are imported. @gniibe's key has meanwhile expired but we keep it because it will allow users to verify some older source packages. An expired signature key is not an error but merely means that one should evaluate the meaning of the signature with more diligence.

Works for a long time now (unless we broke it again;-)

To extend on this: dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems. On Windows we could make it work because DLLs on that platform are well designed and not a hack like the Unix shared objects.

Everything in ~/.gnupg is and has always been private to gnupg unless explicitly stated otherwise.

gniibe: Can you please check what openssl does exactly. The problem is that we currently have no permanent state for Libgcrypt (i.e. something stored on disk per user or even better global)

FWIW: Unfortunately everyone is moving to GCM, even Outlook. While GnuPG was evaluated by the German BSI we had discussions about this and their evaluators were wary about GCM due to its brittleness thus our use of OCB was very welcomed. OTOH, another approved product meanwhile comes with GCM for S/MIME and thus it seems thatGCM is accepted.

Sorry, this is not acceptable to me. <rant>You don't change racism by avoid words which are may be connected to racism. Master is a term used for example to indicate that a person is proficient in her profession. Slave is (in theory) a historic term to describe, well slaves. That is humans who are non-free and are not allowed to control their lives - like the majority of humans these days - they are just called different and the methods of suppression are different than in the past. In fact a Roman slave (but not a medieval bondsman) had well defined and esteemed rights not something the majority of US citizen with a dark skin has in practice. Term abolished, racism abolished, works as good as freeing the US slaves in the 1856, the 1960, or still today. It did not work. Mr. Kings hope has not yet realized itself and is now maybe farther away than we all had hoped in the second half of the last century. Don't cover facts by changing words used in a very different context.</rant>

That reminds me that we we should replace libgcrypt's internal debug functions by those from gpgrt. We have a dependency for gpgrt anyway and thus we should avoid code duplication. Sure we will keep the existsing public functions but that is easy given that gpgrt comes with gpgrt_logv since 1.28 which we can make mandatory (currently libgcrypt requires 1.27 (from 2017, with 1.28 is from 2018)

Check that the file exists and that you have permissions to read the file. You may use an editor to try this out.

With the planned new context aware pubkey functions we technically could do this change w/o an ABI break.

It is a matter of the used font. 2.2.29 will fix this problem.

The original idea with the DNS code was just to source copy it but it turned out that we need to maintain it in GnuPG. Thus adding support for SHA256 makes sense to keep the code current in case we ever need to use it.

wk at gnupg dot org but better avoid any HTML parts etc.

Thanks for the report.

Needs to be tested with the current 2.2 version and a gcry_log_debugsxp should be added to the error output.

This will not be fixed. Brainpool is a standard feature of Libgcrypt and thus this is a bug in the used Libgcrypt installation. Note that although I recently fixed a new regression test for this case, I do not think that it is a good idea to add extra code for a broken Libgcrypt.

This has been solved in 2.2.26 commit rGc75fd75532

That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:

Will be in 2.2.29.

Thanks. I added it to the list. If you have not yet done this I would suggest to write a note to gnupg-users.

We need to see how to best fix this regression test for all Python versions.

We should not support a different OID or representation of 22519 which will only lead to incompatibilities and trouble existing users. 25519 is in too widespread use than to allow for any changes.

FWIW: We have always refused to support shared mode because we anticipated such problems. However, we have a customer using their own cards along with card maintenance software of them. For their purposes PCSC_SHARED works just fine makes and this is why I decided to add --pcsc-shared along with a warning that it is in general not a good idea.