[pkg-fetchmail-maint] Bug#706045: Bug#706045: help?

[Tomas Pospisek]

@Vitezslav Crhonek: I'm Cc:ing you here. Maybe you did a review of 
the patch and I hope you can maybe shed some more light on the discussion 
below.

On Sat, 27 Apr 2013, Adam D. Barratt wrote:

> On Fri, 2013-04-26 at 08:52 +0200, Nico Golde wrote:
>> * Tomas Pospisek <tpo at sourcepole.ch> [2013-04-25 11:29]:
>>> This bug being a RC blocker: is anyone of the fetchmail maintainers working on
>>> this bug ("mimedecode option drops last message line if it is unterminated")?
>>> Shall I try to integrate the patch and do a NMU?
> [...]
>> Feel free, otherwise I'll probably fix it next week. Sorry I'm traveling right
>> now...
>
> The early part of next week is probably doable, but still a little tight
> in terms of getting even an urgency=high package migrated.
>
> I do wonder how many people this actually affects if it's been known
> about since 2011 and not reported to Debian before.

The problem occurs only, if the user sets the mimedecode option. That 
option is used to convert quoted-printable to 8-bit in MIME messages, 
which I *think* is quite an exotic feature, which not many people will 
use, since most mail clients should be able to handle quoted-printable by 
themselves.

Nevertheless, if one of our (Debian's) users *is* using that feature, 
plus he gets a message, whose last line of the mime encoded data is not 
newline terminated, plus fetchmail is configured as to be "destructive" 
i.e. it fetches the mail and deletes it on the remote site, then the 
contents of the received mail can be rended unusable and unrecoverable.

However - if the sender is a human being, then the recipient can still ask 
the sender to provide him the data through a different channel then mail.

But still, data loss for the user can occur, which we absolutely 
and certainly do not want to inflict on anybody.

I have had a look at the patch and as an outsider to the fetchmail code 
that is not a maintaner of fetchmail am personaly not comfortable with 
it. The problem is that the patched code in question is allready twisted 
enough, it's in very large part code to work around various buggy mail 
software that f.ex. doesn't signal the content length correctly. So 
dynamic content lengths and fixed buffers are passed around and written 
into and added to. The provided patch now adds on top of all of this yet 
another work around that adds a newline at the end of the buffer in order 
to get the transformed mime encoded content right.

In short, in the time I was looking at the patch, I was not able to 
determine, if it doesn't add a buffer overflow. To me as an ignorant 
fetchmail code outsider the code in question does contain buffer overflow 
code smell.

Of course both the fetchmail code and the patch are coming from a 
maintainer that does a diligent job, so we can just decide that we trust 
his work without further questions and apply the patch as is (according to 
[1] fedora has applied the patch). In this case I can certainly build and 
upload the patched fetchmail version - the patch applies cleanly.

Please do not understand this as putting Matthias Andree's ability in 
question in any way. It's just my limited code review capabilites.

Opinions?
*t

[1] https://bugzilla.redhat.com/show_bug.cgi?id=955814#c2