Re: [GMime 3 Branch] IMAP build error



Hi Peter!

Am 25.11.19 18:45 schrieb(en) Albrecht Dreß:
Hi Peter!

Am 25.11.19 05:01 schrieb(en) Peter Bloomfield:
So, as of commit 8cfe5a7ebc7bce9c960da8932de2152020e39de7, I can build the branch and run it. It still shows 
current messages' signatures as broken. But if I send a signed, not encrypted, message to myself, the 
signature is OK. Don't know what this means!

I guess the gmime3 branch somehow confuses line endings, both when creating and checking signatures.  
Remember that the RFC's for GPG and S/MIME all *require* canonical line endings (e.g. RFC 3156, sect. 5).


As result of a /very/ quick look I think you just used the wrong encoding direction for the canonical line 
endings:

<snip>
diff --git a/libbalsa/gmime-multipart-crypt.c b/libbalsa/gmime-multipart-crypt.c
index 7526eee54..68c3db948 100644
--- a/libbalsa/gmime-multipart-crypt.c
+++ b/libbalsa/gmime-multipart-crypt.c
@@ -133,7 +133,7 @@ g_mime_gpgme_mps_sign(GMimeMultipartSigned * mps, GMimeObject * content,

     /* Note: see rfc2015 or rfc3156, section 5.1 */
     filtered = g_mime_stream_filter_new(stream);
-    filter = g_mime_filter_dos2unix_new(TRUE);
+    filter = g_mime_filter_unix2dos_new(TRUE);
     g_mime_stream_filter_add(GMIME_STREAM_FILTER(filtered), filter);
     g_object_unref(filter);

@@ -278,7 +278,7 @@ g_mime_gpgme_mps_verify(GMimeMultipartSigned * mps, GError ** error)
     filtered_stream = g_mime_stream_filter_new(stream);

     /* Note: see rfc2015 or rfc3156, section 5.1 */
-    crlf_filter = g_mime_filter_dos2unix_new(TRUE);
+    crlf_filter = g_mime_filter_unix2dos_new(TRUE);
     g_mime_stream_filter_add(GMIME_STREAM_FILTER(filtered_stream),
                             crlf_filter);
     g_object_unref(crlf_filter);
</snip>

At least RFC 3156 signed messages are now validated correctly.  I didn't check signing and S/MIME (RFC 8551) 
yet, but I *think* it will also fix the issue.  I'm not sure if the “TRUE” arg for the filters is correct, at 
least for validation.

Interestingly, RFC 4880 (old single-part OpenPGP) validates without further changes.  Of course, we must also 
ensure proper line endings there…

Cheers,
Albrecht.

Attachment: pgp4qKRFedV7C.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]