This is a screenshot I received in November. What is shows is that Enigmail got the error from gpg and displays an error. However, the plaintext is also displayed (the garbled stuff) and would thus trigger the explot. But first the user has to agree to it (the blue TB warning). So this screenshot actually shows that the exploit did not work.

The path I now took is to keep 2.2 as is but change GPGME to trigger a decryption failure if no MDC is used. This is under the assumption that old scripts using gpg 2.2 or gpg 2.0 do not use GPGME.

You mean because they mentioned 64 bit block ciphers? In the original mail exchange in November about "we have broken the MDC" which we disproved and they confirmed that it is an Enigmail or Thunderbird problem:

That was actually our old stance on OpenPGP encryption: For integrity we rely on the signing of messages. Remember that signing is an integral part of OpenPGP messages and does not need MIME. Some people explained that they have valid reasons not to sign and so we added the MDC.

Yes, this is on purpose, we display only the most important commands, similar to --help

Actually this is not related to the mentioned CVE because the issue we are talking about has not been tested by them.

Done in master with rGd1431901f014 and we are discussing on Jabber whether we can risk to do that in 2.2 too. It might be that another ortion than --ignore-mdc-error would be better for 2.2 but that would differ than from master.

That comes directly from pthread_attr_init - need to check what's special on HP/UX here.

Do you have any other implementation to test against?

A smartcard may do several dozen operations per second and thus spawning a tool each time is not the best option. A generic notification scheme would be better. OTOH, notifications about secret key operations may accidentally create an oracle - which is not good.

It seems that Debian does not install te required libgpg-error correctl.

The fingerprint is required because that is the unique identifier for a key. Without that we would need to presetn a menu to select between keys. This would make scripting complicated again. On the command line c+p is easy enough to hget the fingerprint. c+P is also the reason why we print the fingerprint by default without spaces.

You are lucky. This has been possible for quite some time and since 2.2.6 it is an official part of the API. See T3816

The key receives fully trust and thus we get the "green" flag plus the "expired" flag. In my test with OpenPGP the key was not trysted and thus we did not got only the "expired" flag. At some distant past we agreed on these rules.

gpgsm behaves exactly as gpg and as explain in doc/DETAILS. VALIDSIG is issues even for signatures done by an expired certificate. Let me check whey GPGME claims "green" here while it does not not an expired OpenPGP signature.

Am I right to assume that the test suite is terminating and restarting libgcrypt? Although we have features for this, I am still not convinced that this is a proper use of libgcrypt. There are just too many cases how this can fail. Unix is not designed to use shared libraries in so-called "plugins". I need to look closer at the libssh code.

It seems to be 1.1.6 from 2010 or so. They use gpg 1.4.20 which misses a critical security fix.

This bug tracker does not support gpg4usb - please use their bug tracker.

Workaround is to click cancel so that the next key is tried; right?

Do not define NDEBUG - defining this is a bad idea. Anyway, I will fix that problem.

Thanks.

I assume -z0 could be used as a workaround but without compression then.
Fix goes into 2.2.7 to be release tomorrow (tm)

Confirmed. it is also not Windows specific.

It is in 1.30 which I released a few minutes ago. Only minor other changes.

No, we won't cripple GnuPG for testing purposes. You intended to test something else than the provided GnuPG.

Please don't apply this, SYSROOT is not a well defined feature and it needs to be implemented everywhere in the same way.

SYSROOT support is not yet fully implemented. You need to give the --with-foo options for each package.
I will retitle this bug to indicates tha tit is a feature request.

Looking again at this: There is a reason why I used the simple permissive license for _that_ file and didn't referenced the Program (GnUPG) here:

BTW< you should add an SPDX-Licence-Identifier while you are changing the boilerplate.

See also T2448

This for importing passwords using a somewhat heuristic approach to accommodate for all the weird things other PKCS#12 implementations do. I have not looked into the specs for a decade and thus can't tell you the reason for that limitations. There might have been one back then. In any case PKCS#12 is the most insecure things in the PKCS suite and it is questionable whether this can be called a standard.

The nonce is a string of octets thus it needs to be passed verbatim. I would need to study the code in libassun/src/assuan-socket.c to tell more.

The chained status handlers are a problem in general. I will think about a more robust solution for 1.12

Right now building the release.