Feature suggestion: options to require MDC or trusted signature on decryption

Patrick Brunschwig patrick at enigmail.net
Tue May 29 08:14:40 CEST 2018

On 28.05.18 11:24, Werner Koch wrote:
> On Thu, 24 May 2018 10:53, fgrieu at gmail.com said:
>> [1] cause gpg to supress any deciphered output that is not
>> integrity-protected by at least one of MDC or trusted signature; I do
>> realize this requires buffering when using gpg as a pipe.
> Buffering is not the task of gpg and simply not possible.  This needs to
> be done by another layer.  I already remarked elsewhere that I plan to
> do this to GPGME when using in certain ways (ie. in memory or on files).
>> [2] cause gpg to exit with non-zero status whenever an input was
>> deciphered (output or not) and was not integrity-protected as above.
> This is already the case unless a user is using a very old key and never
> updated the expiration date or the preferences.  I have some doubts that
> such a key will be used with proper OPSEC.  Note also that tehre are
> widley used OpenPGP implementaions which support only AES and major
> interoperablity problems have not been reported.  This is another
> indication that the use of the legacy algorithsm (IDEA, 3DES, CAST5) are
> quite rare.  Anyway, in master we now fail hard for _all_ cipher
> algorithm, regardless of any preferences.
> We need to discuss whether to backport this to 2.2.  I meanwhile tend to
> say yes.

Enigmail fails with this since about two weeks, also for older versions
of GnuPG. I had a number of bug reports/support requests since then, but
overall it was less than I feared. Some people still have very old keys.
The major pain point for them is access to their old emails.

This can be overcome, for example by having specific functions in the
user-facing application that ignore the GnuPG status. That said, yes I'm
in favor of backporting this, but we need to make the developers of
tools using GnuPG aware of the change early enough such that they can
prepare their software. Otherwise we'll leave behind a number of unhappy


More information about the Gnupg-devel mailing list