difference in output between 1.4.x and 2.0.x when agent fails to sign -- causes enigmail to send broken messages
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
> * 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