In another report, it turned out to be, that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

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.

Please update to Gpg4win-3.1.1 this issue should be resolved. There was a similar issue with Gpg4win 3 T2670 but it has been resolved.

We've analyzed another report of this and the problem turned out to be that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

@werner I was hoping to make a modified gpg-agent build that would let me walk through what's going on after the nonce is sent but it looks like the gpg4win process only takes in a package of pre-built gpg binaries which rules that out. As far as I can figure out, after the nonce is read and accepted, libassuan creates a stream object out of the socket and then finding nothing in the stream terminates the ssh handler. We send the actual client request immediately after the nonce but in a separate call to send() so I now wonder if by not having anything read in at the same time as the nonce gpg-agent or libassuan thinks that it's a 0-length stream.

Yes. For S/MIME we don't have the comfort to change the standards. I also would like to have a quick solution. After much deliberation with Bernhard we think that it is a good compromise from usability vs. security that we further reduce the usability for S/MIME in that we only allow (any) signed content to be displayed as a file or HTML. This is not extending the standard, not changing GPGSM but a design decision in GpgOL.
We don't have full control over our Mail client so we can't prevent the load of external references like KMail does. This suggestion is a compromise and a pragmatic solution.

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.

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

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

Thanks for testing. A new Gpg4win release will come soon.

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.

Thanks. Confirmed - no crash with the beta5 dll.

Argh! From the log it looks very much like another incarnation of the issue fixed in T3960 (Same underlying reason)

Good idea, but I've already tried it. Tried once again and freeze still occurs.

Webhelp version of the Python bindings HOWTO is currently available here:

Hi and thanks. Yes, I consistently reproduce. Here's the log file.

As a work-around for this bug I've ported the HOWTO from org-mode to DITA XML and will generate a webhelp-responsive (i.e. searchable) version to put on another website (an Amazon S3 bucket since it will be reliable and cheap) in the interim.

Okay, so maybe this has nothing to do with T3748 then…

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?

Above command freezes with 100% CPU, too.

Thanks for your report!

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.

Org-Mode was updated to today's release and further testing was conducted.

cross-sign is also missing.

If you never explicitly changed the default trust model, then I would expect you are not using TOFU, but the presence of a tofu.db file strongly suggests that you are indeed using it.

I'm not sure. How to check it? In man gpg I only see instructions on how to change the trust model. ~/.gnupg/gpg.conf does not have any trust model related entry. I have ~/.gnupg/tofu.db file however.

This looks reminiscent of a bug previously seen in GPA (T3748).

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

Zertifikat erneuert.

I've already sent jens a mail this morning.

I understand the Problem. Your recipient formatted the reply in such a way that GpgOL does not detect that the original message is Quoted, verifies it and shows only the verified part.

Great! I did not notice this feature!
Is it on purpose that this is not shown by hitting TAB in the --edit-key command prompt (and auto-completion)?