@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 <t...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
