On Mon, 10 Nov 2014 21:52, d...@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 OpenPGP. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ enigmail-users mailing list enigmail-users@enigmail.net To unsubscribe or make changes to your subscription click here: https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
