GNOME Bugzilla – Bug 737930
Claims invalid PGP signature for single line mail
Last modified: 2014-10-21 05:48:33 UTC
How to reproduce: 1. check "PGP sign" in Options 2. write email (Plain-Text) but do not hit return at the last line 3. send 4. check Sent Folder, it shows invalid signature Workarounds - send HTML mails - add empty line at the end I don't see this behavior with 3.12.6
issue started with https://git.gnome.org/browse/evolution/commit/?id=8650fb13
it appears that the text returned by gtkhtml_editor_get_text_plain() was always terminated by '\n', so a quick fix could be diff --git a/e-util/e-html-editor-view.c b/e-util/e-html-editor-view.c index 166f345..5487ba8 100644 --- a/e-util/e-html-editor-view.c +++ b/e-util/e-html-editor-view.c @@ -6648,6 +6648,10 @@ process_content_for_plain_text (EHTMLEditorView *view) else g_object_unref (source); + if (!g_str_has_suffix (plain_text->str, "\n")) { + g_string_append (plain_text, "\n"); + } + as for the root cause, my current working hypothesis is a miscalculation of outlen in mime_filter_canon_run()
what I think is the root cause of this issue - before the text is passed to GPG it gets filtered - the filter is added to the output stream - camel_mime_filter_canon does some magic until \n is reached and puts the rest into backup buffer for later processing - since camel_mime_filter_complete is never called from stream_filter_write, the content of the backup buffer is lost, because outlen is only calculated based on o, if last==TRUE, starto is used otherwise, but starto is only changed if \n is found, which is not possible because e-html-editor-view is not returning trailing \n I'd be interested to learn why stream_filter_write is not calling camel_mime_filter_complete?
Created attachment 288613 [details] [review] filter input, not output since stream_filter_read does call camel_mime_filter_complete, filtering the input should fix the issue
Thanks for a bug report and patch. While SMTP RFC requires a CRLF use as a line break [1], the message can come also from other sources, either 3rd-party plugins or even from disk files which can have the line breaks converted into LF only. That's the reason for the filter. When you remove it, you'll break other part of the expectations. It'll be better to fix the canon filter to not hide data from the stream, ale because any other usages of that filter will stay still broken after the proposed patch. [1] https://tools.ietf.org/html/rfc5321#section-2.3.8
I don't understand why this patch was rejected. The patch does not remove the filter. Current code istream canon_stream | | | filter | | +--write_stream--+ Patch istream canon_stream | | filter | | | +--write_stream--+ a similar code sequence is used in camel_multipart_signed_get_content_stream lines 811-828
Ouch, I misread your changes, it seemed to me that you dropped the canon stream completely, which is not true. I'm sorry for that. Created commit 85dd1b8 in eds master (3.13.7+) [1] Created commit e6fc880 in eds evolution-data-server-3-12 (3.12.8+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=85dd1b8