difference in output between 1.4.x and 2.0.x when agent fails to sign -- causes enigmail to send broken messages

Werner Koch wk at gnupg.org
Tue Nov 11 15:45:25 CET 2014

On Mon, 10 Nov 2014 21:52, dkg at fifthhorseman.net said:

> I believe this is two distinct issues, and maybe we want to address them
> both:
>  * gnupg 2.1.x might want to buffer data before the signature is made,
>    and decline to emit anything if the signature fails

There is a lot of buffering going on and that may be the reason for the
different behavior.  Given that gpg is designed to work in a pipeline,
it does not store any data and thus a cancel or any other error may
leave unfinished output.  If we know that we are writing to a file
created by us, that file is removed on error - but for obvious reasons
not if it goes to stdout.

What we can do is to start implement a pre-sign command in gpg-agent
which unprotects the key and then waits for the actual sign command at
the end of the input data (which may take some minutes for large file).
GPGME's UI-server protocols defines something similar.

>  * enigmail probably should detect that its invocation of gpg returns a
>    non-zero error code and raise an error in the message creation step.
>    I note that it appears to do so properly for when generating non-encrypted
>    PGP/MIME-signed messages, it's just failing at PGP/MIME
>    encrypted+signed messages.

Maybe because of that ugly micalg MIME parameter which inhibits one-pass
processing?  We should anyway ignore that parameter - it is useless for



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list