Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

Won't fix for 2.2 or CFB encryption.

My bad. I looked at the wrong working copy. Will pick that commit.

No, it is your fix: rG278d87465685: gpg: Clear the symmetric passphrase cache for encrypted session keys..
Please cherry pick it to 2.2 branch.

Slight addendum: MSYS2 isn't even part of MinGW at all, see the commentary in this bug report. Nor is it a part of Cygwin, but apparently it is a part of a fork of Cygwin.

Not only is this not supported, but I've now confirmed that MSYS2 isn't even supported by its own project and they direct all downloaders to their MinGW-get installer.

Thanks. The entire getkey.c code better needs a complete overhaul for before we add v5 keys.

We have a workaround thus lowering the priority.

It seems @gniibe fixed that en-passant in master. At least I can only replicate this with 2.2.

Ok yeah. I can aim for a Gpg4win for next week, too.

next week?

What is the ETA for 2.2.9?

Finally changed it. Especially for keyserver search this was important.

The comment is a bit misleading. It does not fix the crash because it all depends on the stack layout: printf takes the args from the stack and if there are not enough args pushed by the caller printf happily uses args which are the local vars from our printf function. Clearing a few vars there seems to have the effect that the args for the "%s" now points to a NULL. In fact you can't fix such crashes with any stdarg function on any platform I know. That is why gcc as a couple of helpful attributes to detect misuse of stdarg args at compile time (e.g. sentinel, printf).

It won't import that keyblock. We can fixup some trivial cases but there will always be ways to create a garbled keyblock and that is nothing we can fix. Better restore the keyblock from a backup or write a dedicated tool fsck-like tool.

IMO this can be closed. At least the problem for which I intended this ticket is fixed.

I agree that the underlying problem is something else but I also think that if a function can avoid a crash on bad input it should try to do so (or at least assert).

I'm going for Wontfix here. It's just too verbose and I don't really see the point of that additional information.

Though a CFFI/ABI solution may be the only option, it would still be preferable to get SWIG working under Windows. The reasons for this are many, but not least of which would include not needing to duplicate effort to accommodate Windows, no functionality mismatch due to using the Windows version and not needing to implement every function manually since CFFI can't generate low level bindings the same way that SWIG does.

What happens, if other bad packets beside PKT_USER_ID, PKT_ATTRIBUTE, PKT_OLD_COMMENT, and PKT_COMMENT are found?

Printing "(null)" is just coincidence because NULL is stored at the respective stack address on one platform.

The patch fixes a symptom of wrong format specs usage. What happens with %s with no supplied arg depends on the platform and what is currently on the stack. So it will always be incorrect and you can't do anything about it except for letting the gettext tools checking the PO files for correct format specifier usage. In the english version gcc does the check.

Well I'm pretty sure the reason is that valuetable_buffer is not inialized in _gpgrt_estream_format. But the resulting behavior confused me. It would not crash. But it would also not print "gpg: Entschlüsselung als fehlgeschlagen angesehen: (null)" It would just print nothing instead of that string.

Thank you for your prompt response and your suggestion for a workaround.

Got it. The reason was a broken translation. I've opened T4054 to fix in general that broken translations can cause crashes.

I can reproduce it with a german windows

Thank you for your detailed report!

Now we have this:

Fixed for master and 2.2.9.