Add --expert and use a decent version of GnuPG. 2.2 is our long term support branch and is not the current stable production version (which is 2.3.7)

Perhaps --full-generate-key should provide more algorithm choices, then, e.g. ed25519?

Sorry, this as been discussed ad nausea. We try our best to help people not to use useless and harmful (e.g. performance of the WoT) algorithm choices.

ENABLE_NLS is not defined as it should be but we still have to define L_ in that case if simple_gettext is used to have some gettext. This was fixed by 6158811304937b592601ef30c29c5a5cdbaa88ea

auto-key-locate now defaults to "local,wkd" and --auto-key-retrieve is also the default.

Yes, any auto-key-locate entry should disable the defaults.

IMO for now we should not add DANE as this has been published for a while and we don't see widespread adoption. To avoid additional delays I would keep it disabled by default for now. But you know the pros / cons there better then me.

So your suggestion is that

auto-key-retrieve
auto-key-locate local
auto-key-locate wkd
auto-key-locate dane

shall be the new default unless --disable-dirmngr is also used?

A new installer is now available:

Patched installer is better. This is also a good test on whether the build works with custom patches.

Or you publish some gnupg-2.1.23-beta3 or so. Would also be ok imo.

I'd say a patched installer with a different date. This is how I would have handled this in the Gpg4win 2.x times.

How, shall we build just a new patched installer or do a full new release?

That was an easy one.

Workaround is to add

Sorry. Git log had some ...skipping which i overlooked instead of 3419a339d9c4e800bf30e9021e05982d8c1021c1 the actual one is 9b43220b8ad1a5c1cd51de3bbfff7ccbcc3fa877

It's either rev: 5b9025cfa1f9b1c67ddf2f6bf87d863e780cf157 which does not compile by itself or 3419a339d9c4e800bf30e9021e05982d8c1021c1

Uhm. I can't reproduce this with a dirmngr built on my development system.

That real bug is not a bug but a wrong error message. Due to the use of OCB we catch passphrase by means of that AEAD mode and not by looking at the cleartext. That resulted in a wrong error message. Fixed to return Bad Passphrase instead.

Segv/ref-count error found. Now for the real bug ...

I tried to reproduce this through various scripts in variations of

Hmmm.

From this I take it that the checksum error comes from gcrypt but is wrongly propagated as Pinentry error.

With the vsnfdhome attached to this report:

I don't understand the GPG_ERR_CHECKSUM coming according to Justus' log from Pinentry. A likeley reason for that error is an OCB decrypt failure in Libgcrypt (e.g. extended protected key format) - but from Pinentry?

Maybe related: T3187

I'm in a checksum error scenario again.

This is very odd indeed. Here is my guru log, it is the same as yours, but except of dying of the assertion, it just continues:

Yes, signing failed: Bad Passphrase but that may be later.

I only get checksum errors: