[PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init()

2013-09-10 Thread Austin Clements 
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

2013-09-10 Thread Austin Clements 
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()

2013-09-10 Thread Jani Nikula 
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

2013-09-10 Thread Ramakrishnan Muthukrishnan 
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

2013-09-10 Thread Daniel Kahn Gillmor 
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()

2013-09-10 Thread Austin Clements 
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()

2013-09-10 Thread Daniel Kahn Gillmor 
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

2013-09-10 Thread David Bremner 

> 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

2013-09-10 Thread Mark Walters 

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

2013-09-10 Thread Mark Walters 

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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread Mark Walters 

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

2013-09-10 Thread Mark Walters 

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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 
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

2013-09-10 Thread David Bremner 

 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

2013-09-10 Thread Ramakrishnan Muthukrishnan 
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()

2013-09-10 Thread Jani Nikula 
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()

2013-09-10 Thread Daniel Kahn Gillmor 
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

2013-09-10 Thread Daniel Kahn Gillmor 
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

2013-09-10 Thread Austin Clements 
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()

2013-09-10 Thread Austin Clements 
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