[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()
LGTM in principle, though I'd like to see a test of some of the malformed RFC 2047 that this lets us decode. Is there a summary somewhere of exactly what these workarounds enable? This isn't directly related to this patch, but is there a reason we g_mime_init in so many different places? Both the CLI and notmuch_database_open I can understand because the CLI also uses GMime and should be sure it's initialized. Maaaybe notmuch_message_file_get_header because notmuch_message_file theoretically independent of the database, even though I don't think it's possible to call into it without first calling notmuch_database_open. But _notmuch_message_index_file? On Tue, 10 Sep 2013, Jani Nikula wrote: > As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: > >> Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() >> *should* solve the decoding problem mentioned in the thread. This >> flag should be safe to pass into g_mime_init() without any bad side >> effects and my unit tests do test that code-path. > > The thread being referred to is [2]. > > [1] id:87bo56viyo.fsf at nikula.org > [2] id:08cb1dcd-c5db-4e33-8b09-7730cb3d59a2 at gmail.com > --- > lib/database.cc| 2 +- > lib/index.cc | 2 +- > lib/message-file.c | 2 +- > notmuch.c | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/lib/database.cc b/lib/database.cc > index 5cc0765..bb4f180 100644 > --- a/lib/database.cc > +++ b/lib/database.cc > @@ -655,7 +655,7 @@ notmuch_database_open (const char *path, > > /* Initialize gmime */ > if (! initialized) { > - g_mime_init (0); > + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); > initialized = 1; > } > > diff --git a/lib/index.cc b/lib/index.cc > index a2edd6d..78c18cf 100644 > --- a/lib/index.cc > +++ b/lib/index.cc > @@ -440,7 +440,7 @@ _notmuch_message_index_file (notmuch_message_t *message, > static bool mbox_warning = false; > > if (! initialized) { > - g_mime_init (0); > + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); > initialized = 1; > } > > diff --git a/lib/message-file.c b/lib/message-file.c > index 4d9af89..a2850c2 100644 > --- a/lib/message-file.c > +++ b/lib/message-file.c > @@ -228,7 +228,7 @@ notmuch_message_file_get_header (notmuch_message_file_t > *message, > is_received = (strcmp(header_desired,"received") == 0); > > if (! initialized) { > - g_mime_init (0); > + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); > initialized = 1; > } > > diff --git a/notmuch.c b/notmuch.c > index 78d29a8..7300c21 100644 > --- a/notmuch.c > +++ b/notmuch.c > @@ -264,7 +264,7 @@ main (int argc, char *argv[]) > > local = talloc_new (NULL); > > -g_mime_init (0); > +g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); > #if !GLIB_CHECK_VERSION(2, 35, 1) > g_type_init (); > #endif > -- > 1.8.4.rc3 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() a test
On Tue, 10 Sep 2013, Daniel Kahn Gillmor wrote: > On 09/10/2013 06:35 PM, Austin Clements wrote: > >> I haven't looked at exactly what workarounds this enables, but if it's >> what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text >> tokens), are there really subject lines that this will misinterpret >> that weren't obviously crafted to break the workaround? > > not to get all meta, but i imagine subject lines that refer an example > of this particular issue (e.g. when talking about RFC 2047) will break > ;) I'm trying one variant here. That's cheating. ]:--8) Though, I wonder, you mentioned in your original email that there would be subject lines that are *unrepresentable* given the worked-around RFC 2047. Did you mean that? If so, can you provide an example? Isn't it always possible to, say, RFC 2047 escape the whole subject, which would be decoded correctly whether the decoder strictly adheres to RFC 2047 or uses the workarounds? (Speaking of which, it looks like message-mode does *not* RFC 2047 encode the subject if it contains text that could be mistaken for an encoded-word, so such subjects won't get round-tripped correctly.)
[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()
As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: > Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() > *should* solve the decoding problem mentioned in the thread. This > flag should be safe to pass into g_mime_init() without any bad side > effects and my unit tests do test that code-path. The thread being referred to is [2]. [1] id:87bo56viyo.fsf at nikula.org [2] id:08cb1dcd-c5db-4e33-8b09-7730cb3d59a2 at gmail.com --- lib/database.cc| 2 +- lib/index.cc | 2 +- lib/message-file.c | 2 +- notmuch.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 5cc0765..bb4f180 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -655,7 +655,7 @@ notmuch_database_open (const char *path, /* Initialize gmime */ if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/lib/index.cc b/lib/index.cc index a2edd6d..78c18cf 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -440,7 +440,7 @@ _notmuch_message_index_file (notmuch_message_t *message, static bool mbox_warning = false; if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/lib/message-file.c b/lib/message-file.c index 4d9af89..a2850c2 100644 --- a/lib/message-file.c +++ b/lib/message-file.c @@ -228,7 +228,7 @@ notmuch_message_file_get_header (notmuch_message_file_t *message, is_received = (strcmp(header_desired,"received") == 0); if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/notmuch.c b/notmuch.c index 78d29a8..7300c21 100644 --- a/notmuch.c +++ b/notmuch.c @@ -264,7 +264,7 @@ main (int argc, char *argv[]) local = talloc_new (NULL); -g_mime_init (0); +g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); #if !GLIB_CHECK_VERSION(2, 35, 1) g_type_init (); #endif -- 1.8.4.rc3
search order
David Bremner writes: > Ramakrishnan Muthukrishnan writes: > >> >> If I startup notmuch and then do a M-x notmuch-search and then *, I see >> the messages with the newest on the top. But if I instead, startup >> notmuch and then hit "s", I see that the new messages are at the >> bottom. The value of notmuch-search-oldest-first is t. >> > > This should be fixed in the latest git master. Thanks for the report, > and thanks to Austin for the fix. :) Thanks.
[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() a test
On 09/10/2013 06:35 PM, Austin Clements wrote: > I haven't looked at exactly what workarounds this enables, but if it's > what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text > tokens), are there really subject lines that this will misinterpret > that weren't obviously crafted to break the workaround? not to get all meta, but i imagine subject lines that refer an example of this particular issue (e.g. when talking about RFC 2047) will break ;) I'm trying one variant here. > The RFC 2047 > escape sequence was deliberately designed to be obscure, since RFC > 2047 itself caused previously "standards-compliant" subject lines to > potentially be interpreted differently. right, and it was designed explicitly to put the boundary markers atword boundaries, and not in the middle of a word (i think that's what this is all about, right?). so implementations which put the boundary markers in the middle of a word, or which include whitespace within the encoded text, aren't speaking RFC 2047. anyway, if there's a rough consensus to go forward with this, i'm not about to block it. I understand that a large part of the business of being an MUA is working around other people's bugs instead of expecting them to fix them :/ I just don't like mis-rendering other text. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130910/19dde093/attachment.pgp>
[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()
Quoth Daniel Kahn Gillmor on Sep 10 at 3:31 pm: > On 09/10/2013 02:51 PM, Jani Nikula wrote: > > As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: > > > >> Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() > >> *should* solve the decoding problem mentioned in the thread. This > >> flag should be safe to pass into g_mime_init() without any bad side > >> effects and my unit tests do test that code-path. > > the result of doing this is that there will become legitimately-crafted > subject lines that are now unrepresentable. > > I'm always leery of trying to improve support for data that doesn't > follow the standards at the expense of data that *does* follow the > standards. > > --dkg I haven't looked at exactly what workarounds this enables, but if it's what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text tokens), are there really subject lines that this will misinterpret that weren't obviously crafted to break the workaround? The RFC 2047 escape sequence was deliberately designed to be obscure, since RFC 2047 itself caused previously "standards-compliant" subject lines to potentially be interpreted differently.
[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()
On 09/10/2013 02:51 PM, Jani Nikula wrote: > As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: > >> Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() >> *should* solve the decoding problem mentioned in the thread. This >> flag should be safe to pass into g_mime_init() without any bad side >> effects and my unit tests do test that code-path. the result of doing this is that there will become legitimately-crafted subject lines that are now unrepresentable. I'm always leery of trying to improve support for data that doesn't follow the standards at the expense of data that *does* follow the standards. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130910/3afe99ce/attachment.pgp>
[PATCH] emacs: show: stop stderr appearing in buffer
> Ideally, we would put this output in the notmuch errors buffer but the > handler is called asynchronously so we don't know when the output will > appear. Thus if we put it straight into the errors buffer it could get > interleaved with other errors, otoh we can't easily tell when we > have got all the error output so can't wait until the process is complete. Hi Mark; I think your patch is OK, but would it be much harder to created a named buffer like *notmuch-view-$message-d* ? (using e.g. the code from notmuch-show). I might make debugging easier. Of course those buffers would accumulate, along with show, search and pick buffers... Or we could push this as is, and add some debugging facility later like a variable notmuch-view-errors-buffer. d
reply to messages with message/rfc822 parts
Hello I was trying to reply to a message I had forwarded to someone (to update the information sent in the first message) and came across some strange behaviour. The initial forward was done using notmuch-emacs: this took the message and sent it as a message/rfc822 mimetype complete message. Since I had added some text at the top this meant the message as a whole was multipart/mixed with my text/plain at the top and the message/rfc822 below. Then I tried to reply to this message and the text/plain part was included in the reply but the message/rfc822 part was not. In this case the message/rfc822 just had headers and a text/plain subpart so I would have expected it to be included. I imagine we actually want to recurse into the message/rfc822 part including relevant subparts. I tried tweaking notmuch-mua.el to do this but, so far, I have failed. (I will have another look) Best wishes Mark
[PATCH 1/3] cli: add insert --must-index option
Hi >> Do you have a particular use case where indexing is required but tagging >> is not? For my uses I would prefer failing if either indexing or tagging >> failed. (My use being postponing messages; If they don't get the >> postponed tag they could be hard to find) > > You're right. > > What about a failure to sync tags to maildir flags? Personally, I wouldn't mind ignoring this failure: it should be relatively easy to fix after the fact (but others may disagree). > I now noticed that database modifications aren't flushed until the > notmuch_database_destroy call (right?), which has no return value and > failure of which is silently ignored. That's acceptable in the default > mode, but with --must-index the failure should be reported (and the > file deleted). Yes I think you are right: flushed by notmuch_database_close which is called by notmuch_database_destroy. Perhaps the easiest would be to add a notmuch_database_flush with a return value and then you can call that (and then call notmuch_database_destroy)? Alternatively maybe add notmuch_database_destroy_with_flush or something which does give a return value. notmuch_database_close is only called 3 times and notmuch_database_destroy lots of times so changing close is much less intrusive than changing destroy. But I don't know whether we would break any bindings or external programs etc. What do you think? Best wishes Mark
[BUG] Decryption fails if message was signed with an unknown key
Simon Hirscher writes: > > $ gpg --recv-keys> > $ notmuch show --decrypt id:xyz at example.com > > [?] > Hey there, > Now the decryption worked! > [?] > Is this related to Jamie's report? id:87obwrix8s.fsf at servo.finestructure.net Jamie, did you ever narrow down the gmime problem? is it fixed in current gmime? d
search order
Ramakrishnan Muthukrishnan writes: > > If I startup notmuch and then do a M-x notmuch-search and then *, I see > the messages with the newest on the top. But if I instead, startup > notmuch and then hit "s", I see that the new messages are at the > bottom. The value of notmuch-search-oldest-first is t. > This should be fixed in the latest git master. Thanks for the report, and thanks to Austin for the fix. d
[PATCH] emacs: add buttons for all multipart/related parts
Istvan Marko writes: > When text/html parts include images as multipart/related and the > text/plain alternative is used these images can be completely hidden > with no easy way to access them or even find out that they are there. pushed, d
[PATCH v2 0/9] emacs: Unify common key bindings and lots more
Austin Clements writes: > This is v2 of id:1377793557-28878-1-git-send-email-amdragon at mit.edu. > This fixes a problem found by Jani where notmuch-hello would reset > point placement when refreshing in Emacs 24. It also inverts the > sense of notmuch-hello-auto-refresh and makes it a defcustom > (originally I'd intended notmuch-hello-inhibit-auto-refresh for > internal use only, but both Mark and Jani expressed interest in > setting it). pushed, d
[PATCH] emacs: show: lazy part handling bugfix
Mark Walters writes: > The lazy part handler had a bug that it allowed the button to be > toggled to be specified. During toggling it needs to save and restore > the text-properties for the button but it actually saved the text > properties at point rather than from the button. pushed, d
Re: [PATCH 1/3] cli: add insert --must-index option
Hi Do you have a particular use case where indexing is required but tagging is not? For my uses I would prefer failing if either indexing or tagging failed. (My use being postponing messages; If they don't get the postponed tag they could be hard to find) You're right. What about a failure to sync tags to maildir flags? Personally, I wouldn't mind ignoring this failure: it should be relatively easy to fix after the fact (but others may disagree). I now noticed that database modifications aren't flushed until the notmuch_database_destroy call (right?), which has no return value and failure of which is silently ignored. That's acceptable in the default mode, but with --must-index the failure should be reported (and the file deleted). Yes I think you are right: flushed by notmuch_database_close which is called by notmuch_database_destroy. Perhaps the easiest would be to add a notmuch_database_flush with a return value and then you can call that (and then call notmuch_database_destroy)? Alternatively maybe add notmuch_database_destroy_with_flush or something which does give a return value. notmuch_database_close is only called 3 times and notmuch_database_destroy lots of times so changing close is much less intrusive than changing destroy. But I don't know whether we would break any bindings or external programs etc. What do you think? Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
reply to messages with message/rfc822 parts
Hello I was trying to reply to a message I had forwarded to someone (to update the information sent in the first message) and came across some strange behaviour. The initial forward was done using notmuch-emacs: this took the message and sent it as a message/rfc822 mimetype complete message. Since I had added some text at the top this meant the message as a whole was multipart/mixed with my text/plain at the top and the message/rfc822 below. Then I tried to reply to this message and the text/plain part was included in the reply but the message/rfc822 part was not. In this case the message/rfc822 just had headers and a text/plain subpart so I would have expected it to be included. I imagine we actually want to recurse into the message/rfc822 part including relevant subparts. I tried tweaking notmuch-mua.el to do this but, so far, I have failed. (I will have another look) Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: show: lazy part handling bugfix
Mark Walters markwalters1...@gmail.com writes: The lazy part handler had a bug that it allowed the button to be toggled to be specified. During toggling it needs to save and restore the text-properties for the button but it actually saved the text properties at point rather than from the button. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 0/9] emacs: Unify common key bindings and lots more
Austin Clements amdra...@mit.edu writes: This is v2 of id:1377793557-28878-1-git-send-email-amdra...@mit.edu. This fixes a problem found by Jani where notmuch-hello would reset point placement when refreshing in Emacs 24. It also inverts the sense of notmuch-hello-auto-refresh and makes it a defcustom (originally I'd intended notmuch-hello-inhibit-auto-refresh for internal use only, but both Mark and Jani expressed interest in setting it). pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: add buttons for all multipart/related parts
Istvan Marko notm...@kismala.com writes: When text/html parts include images as multipart/related and the text/plain alternative is used these images can be completely hidden with no easy way to access them or even find out that they are there. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: search order
Ramakrishnan Muthukrishnan r...@rkrishnan.org writes: If I startup notmuch and then do a M-x notmuch-search and then *, I see the messages with the newest on the top. But if I instead, startup notmuch and then hit s, I see that the new messages are at the bottom. The value of notmuch-search-oldest-first is t. This should be fixed in the latest git master. Thanks for the report, and thanks to Austin for the fix. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] Decryption fails if message was signed with an unknown key
Simon Hirscher pub...@simonhirscher.de writes: $ gpg --recv-keys sender's key $ notmuch show --decrypt id:x...@example.com […] Hey there, Now the decryption worked! […] Is this related to Jamie's report? id:87obwrix8s@servo.finestructure.net Jamie, did you ever narrow down the gmime problem? is it fixed in current gmime? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: show: stop stderr appearing in buffer
Ideally, we would put this output in the notmuch errors buffer but the handler is called asynchronously so we don't know when the output will appear. Thus if we put it straight into the errors buffer it could get interleaved with other errors, otoh we can't easily tell when we have got all the error output so can't wait until the process is complete. Hi Mark; I think your patch is OK, but would it be much harder to created a named buffer like *notmuch-view-$message-d* ? (using e.g. the code from notmuch-show). I might make debugging easier. Of course those buffers would accumulate, along with show, search and pick buffers... Or we could push this as is, and add some debugging facility later like a variable notmuch-view-errors-buffer. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: search order
David Bremner da...@tethera.net writes: Ramakrishnan Muthukrishnan r...@rkrishnan.org writes: If I startup notmuch and then do a M-x notmuch-search and then *, I see the messages with the newest on the top. But if I instead, startup notmuch and then hit s, I see that the new messages are at the bottom. The value of notmuch-search-oldest-first is t. This should be fixed in the latest git master. Thanks for the report, and thanks to Austin for the fix. :) Thanks. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()
As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() *should* solve the decoding problem mentioned in the thread. This flag should be safe to pass into g_mime_init() without any bad side effects and my unit tests do test that code-path. The thread being referred to is [2]. [1] id:87bo56viyo@nikula.org [2] id:08cb1dcd-c5db-4e33-8b09-7730cb3d5...@gmail.com --- lib/database.cc| 2 +- lib/index.cc | 2 +- lib/message-file.c | 2 +- notmuch.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 5cc0765..bb4f180 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -655,7 +655,7 @@ notmuch_database_open (const char *path, /* Initialize gmime */ if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/lib/index.cc b/lib/index.cc index a2edd6d..78c18cf 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -440,7 +440,7 @@ _notmuch_message_index_file (notmuch_message_t *message, static bool mbox_warning = false; if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/lib/message-file.c b/lib/message-file.c index 4d9af89..a2850c2 100644 --- a/lib/message-file.c +++ b/lib/message-file.c @@ -228,7 +228,7 @@ notmuch_message_file_get_header (notmuch_message_file_t *message, is_received = (strcmp(header_desired,received) == 0); if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/notmuch.c b/notmuch.c index 78d29a8..7300c21 100644 --- a/notmuch.c +++ b/notmuch.c @@ -264,7 +264,7 @@ main (int argc, char *argv[]) local = talloc_new (NULL); -g_mime_init (0); +g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); #if !GLIB_CHECK_VERSION(2, 35, 1) g_type_init (); #endif -- 1.8.4.rc3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()
On 09/10/2013 02:51 PM, Jani Nikula wrote: As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() *should* solve the decoding problem mentioned in the thread. This flag should be safe to pass into g_mime_init() without any bad side effects and my unit tests do test that code-path. the result of doing this is that there will become legitimately-crafted subject lines that are now unrepresentable. I'm always leery of trying to improve support for data that doesn't follow the standards at the expense of data that *does* follow the standards. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() a test
On 09/10/2013 06:35 PM, Austin Clements wrote: I haven't looked at exactly what workarounds this enables, but if it's what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text tokens), are there really subject lines that this will misinterpret that weren't obviously crafted to break the workaround? not to get all meta, but i imagine subject lines that refer an example of this particular issue (e.g. when talking about RFC 2047) will break ;) I'm trying one variant here. The RFC 2047 escape sequence was deliberately designed to be obscure, since RFC 2047 itself caused previously standards-compliant subject lines to potentially be interpreted differently. right, and it was designed explicitly to put the boundary markers atword boundaries, and not in the middle of a word (i think that's what this is all about, right?). so implementations which put the boundary markers in the middle of a word, or which include whitespace within the encoded text, aren't speaking RFC 2047. anyway, if there's a rough consensus to go forward with this, i'm not about to block it. I understand that a large part of the business of being an MUA is working around other people's bugs instead of expecting them to fix them :/ I just don't like mis-rendering other text. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() a test
On Tue, 10 Sep 2013, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On 09/10/2013 06:35 PM, Austin Clements wrote: I haven't looked at exactly what workarounds this enables, but if it's what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text tokens), are there really subject lines that this will misinterpret that weren't obviously crafted to break the workaround? not to get all meta, but i imagine subject lines that refer an example of this particular issue (e.g. when talking about RFC 2047) will break ;) I'm trying one variant here. That's cheating. ]:--8) Though, I wonder, you mentioned in your original email that there would be subject lines that are *unrepresentable* given the worked-around RFC 2047. Did you mean that? If so, can you provide an example? Isn't it always possible to, say, RFC 2047 escape the whole subject, which would be decoded correctly whether the decoder strictly adheres to RFC 2047 or uses the workarounds? (Speaking of which, it looks like message-mode does *not* RFC 2047 encode the subject if it contains text that could be mistaken for an encoded-word, so such subjects won't get round-tripped correctly.) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()
LGTM in principle, though I'd like to see a test of some of the malformed RFC 2047 that this lets us decode. Is there a summary somewhere of exactly what these workarounds enable? This isn't directly related to this patch, but is there a reason we g_mime_init in so many different places? Both the CLI and notmuch_database_open I can understand because the CLI also uses GMime and should be sure it's initialized. Maaaybe notmuch_message_file_get_header because notmuch_message_file theoretically independent of the database, even though I don't think it's possible to call into it without first calling notmuch_database_open. But _notmuch_message_index_file? On Tue, 10 Sep 2013, Jani Nikula j...@nikula.org wrote: As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() *should* solve the decoding problem mentioned in the thread. This flag should be safe to pass into g_mime_init() without any bad side effects and my unit tests do test that code-path. The thread being referred to is [2]. [1] id:87bo56viyo@nikula.org [2] id:08cb1dcd-c5db-4e33-8b09-7730cb3d5...@gmail.com --- lib/database.cc| 2 +- lib/index.cc | 2 +- lib/message-file.c | 2 +- notmuch.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 5cc0765..bb4f180 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -655,7 +655,7 @@ notmuch_database_open (const char *path, /* Initialize gmime */ if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/lib/index.cc b/lib/index.cc index a2edd6d..78c18cf 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -440,7 +440,7 @@ _notmuch_message_index_file (notmuch_message_t *message, static bool mbox_warning = false; if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/lib/message-file.c b/lib/message-file.c index 4d9af89..a2850c2 100644 --- a/lib/message-file.c +++ b/lib/message-file.c @@ -228,7 +228,7 @@ notmuch_message_file_get_header (notmuch_message_file_t *message, is_received = (strcmp(header_desired,received) == 0); if (! initialized) { - g_mime_init (0); + g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); initialized = 1; } diff --git a/notmuch.c b/notmuch.c index 78d29a8..7300c21 100644 --- a/notmuch.c +++ b/notmuch.c @@ -264,7 +264,7 @@ main (int argc, char *argv[]) local = talloc_new (NULL); -g_mime_init (0); +g_mime_init (GMIME_ENABLE_RFC2047_WORKAROUNDS); #if !GLIB_CHECK_VERSION(2, 35, 1) g_type_init (); #endif -- 1.8.4.rc3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch