Which reminds me that we should add a cronjob feature to dirmngr (which already does some background tasks) so that we can easiliy make use of --no-auto-check-trustdb on Windows.

Is there any change if you enable the keyboxd to store the keys? Put

To minimize the risk of regressions.

I would prefer to see a fix/hack in pinentry-qt instead.

Cool

I tried a fresh card reconfigured it to use 3 4k RSA keys:

See T2368

Hmm, do we need a backport?

Please try 3.1.16 and make sure that you don't have other variants of gpg4win installed or Outlook plugins also using parts of gpg4win or its libraries.

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.