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.

We didn't found the time to organize it. There will be a OpenPGP summit this fall organized by Patrick, though

Will be released with 2.2.9

Fix will also go into 2.2.9

changing to testing is our marker for "done in code but not fully tested / released". It helps to keep an overview of the issues which are "done" for the next release.

Hi Andre,

Do you have Tor or the Tor Browser running? Dirmngr will use them instead of a direct or proxy network connection. Di disable this behaviour put

no-use-tor

into dirmngr.conf. If that is not the case we need some more debug info. Put

log-file SOMEFILE
verbose
debug network,dns

into dirmngr.conf and post the log file (or send privately to wk@gnupg.org mentioning T4044 in the subject - no HTML please).

We have two cases:

1. No MDC with a "modern" cipher algo

This is implemented now and can be turned of in the new config dialog.

ASCII Armored CMS files now also use p7m and p7s this is already handled gracefully by Kleopatra and does not require us to register new filetypes.

I find this better then a new "KEYLIST_MODE_WKD" as it is more flexible and this flexibility with context flags is currently our thing anyway.

This is really minor, just wanted to report it so it did not get forgotten.

I don't think that this was ever working the Outlook 2007 code has been pretty much unchanged since 2013.
According to T1137 a workaround seems to be to enable the S/MIME Support in GpgOL.

Thanks very much for your help! Could you please tell me the latest version, that is running without any mistakes on outlook 2007?

Outlook 2007 is no longer supported. Neither by Microsoft nor by GpgOL. Sorry for that. But the 2010 and later GpgOL had a completely different codebase and we had to remove the support at some point.

Backport done. To be released with 2.2.9.

Fixed in master and 2.2 branch.

I found two more cases. Those are included in the fix.