Re: [Pan-users] filter in task list

[Duncan]

Thomas Fricke posted on Sun, 07 Jun 2015 21:56:14 +0200 as excerpted:

> sorry for the late response. Evolution really does not like your message
> somehow. If I hit the reply button it segfaults right away :-)

Hmm... interesting.  As you can see from my headers if you check (or if 
you have the user-agent header displayed if included, as pan does), I'm 
actually posting with pan, via gmane.org's list2news service.

So evolution doesn't like something from one of:
a) the pan post itself, as sent
b) one of the headers (like received) that's routinely inserted by mail 
servers as they process the mail
c) one of the headers the gmane list2news (or here, the reverse, 
news2list) service inserts, as it processes the news post and forwards it 
as mail to the list
d) one of the headers (like list-help) the list-serve inserts... tho in 
this case you probably couldn't reply to other list posts either.
e) some corruption introduced somewhere along the way
f) something else I've not thought to mention in the above list.

I've actually seen pan have similar issues, except on display of the 
post, not on reply.  Because of the way pan works, storing the individual 
messages as files, I have been able to actually bisected the problem down 
to a single line and often to a single character, in several cases.

Basically, I find the file in pan's cache, then make a good copy of it to 
restore as I need to while I experiment.  I'll often start by replacing 
most of the body with say a single "Body" word, then trying to load the 
post in pan.  If that works while it didn't originally, I know the 
problem is in the body.  If it doesn't, I know it's in the headers.

If it's in the body, I can simply bisect the body, trying one half and 
seeing if it works, then either adding or deleting half of the problem 
half, repeatedly, until I get to an individual line or at least an 
individual sentence or paragraph.  With a bit of experience, I've learned 
to scan the problem text from there, looking for a non-standard 
character, perhaps a non-break-blank-space or some such, that doesn't fit 
in the claimed charset or that pan is otherwise likely to choke on.  
Usually I can find it, then confirm by replacing that character with 
something else and verifying that pan no longer chokes on it.

If it's in the headers, I similarly bisect and scan them for something 
that doesn't look correct, except header formatting is much stricter than 
body formatting, so it's often easier to spot, and even if not, there's 
usually far fewer header lines than body, making bisecting a faster 
process.

FWIW, one problem pan still has, AFAIK, is that if the MIME headers say 
there is supposed to be an attachment and it's missing, say because it 
was malware and was thus stripped, but leaving in place the header that 
claims it's there, pan can segfault on that.  I thought I had filed a bug 
on it, and certainly reported it on the pan-dev list and kept a 
reproducer, but I don't see the bug filed now, so maybe I didn't.  I'll 
have to check a bit better and do so if I haven't...

Meanwhile, regardless of what evolution is fed, it shouldn't /segfault/.  
I'd strongly suggest doing a similar bisect and report, preferably first  
testing with a current version if yours isn't, just in case it's already 
fixed, because segfault bugs, particularly on applications that process 
untrusted incoming data such as mail, are a strong indication of a 
possible security issue (segfaults with accidentally bad data can often 
be turned into execute-arbitrary-badguy-code bugs with more deliberately 
exploitable bad data), and should be treated as such until they are 
either fixed or at least inspected by experts who can figure out whether 
they're a security issue or not.  (Generally, it's just easier to fix 
them, once a reliable reproducer is found so the bug can actually be 
traced.  This is the approach the Linux kernel folks normally take, for 
instance, fixing the bug without actually determining whether it is a 
security issue, thus the standard "all users must upgrade" advice on 
stable kernel releases.)

And of course if the problem is in an original header that pan produced 
or in the body as posted, then filing a pan bug on it as well, should be 
considered, since in that case pan's output may not be standards 
compliant, or it may be standards compliant but still not recommended 
output, given the number of would-be readers/repliers that may have 
problems with the post.

One other possibility.  What version of gmime are you running?  I traced 
one originally pan problem to a bug in the gmime library, versions 
2.6.16-2.6.18.  2.6.15 didn't have the buggy code yet, and 2.6.19 fixed 
the bug, but if you have one of the versions in the affected range 
installed, that's almost certainly the problem right there.  File a bug 
with your distro and have gmime upgraded to 2.6.19 or later.  (FWIW, I 
now have 2.6.20 installed here, on gentoo/~amd64, ~ indicating testing, 
so normally reasonably new versions.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman