[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

the right bug severity in case of data corruption


I've recently reported several bugs against MUAs and mail tools, that
employ the mboxo (note the trailing "o") format to either store or
import mails.

This however leads to irrecoverable data corruption, as the partial
quoting of so called From_ lines cannot be undone anymore.
An easy solution for that dilemma is known for years, namely the other
mbox formats (either mboxrd, mboxcl or mboxcl2), of which mboxrd is
typically the one which fits best the needs for staying backwards

Given that mails are the core business and data of MUAs and mail tools,
I'd personally say that any corruption of them, even if it seems to be
minor deserves the most critical severity.
Similarly, if a DBMS like postgres would silently modify integers, even
if joust a tiny bit, it would be considered unacceptable.

For mails one may easily think, that a "small" corruption isn't a
problem, but not only does it break signatures or perhaps corrupt
in-line content like patches, it's IMHO also not the decision of
upstream, the maintainers or anyone else but each single user which kind
of corruption of his data he/she considers to be severe.

No first I've had reported these corruptions at the different upstreams
(and apart from KMail and mutt...all the major players I've tested, e.g.
Thunderbird, Evolution, getmail, postfix, were affected).
Apart from the getmail upstream all reacted rather stubborn and without
much insight,... bringing up obscure "arguments" like "this corruption
has always been the case historically, therefore it's ok".
Well we, as Debian, can't of course force upstreams to fix their crap,
but IMHO neither should we let our users at risk for silent data

So I've opened bugs at the BTS, too, with severities critical
(justification: data loss) where I mentioned the upstream bug and
further suggested what I think we should do at the Debian level to
adequately warn users.

IIRC, in all but the getmail case (where the issue has been fixed)
upstream, this was neither accepted by the Debian maintainers, referring
to the same obscure arguments from the upstreams.

I personally have no longer much interest in tracing this family of
issues, especially when being confronted with so much narrow-mindedness
and arrogance (IMHO, deciding for the users that they can live with mail
corruption is arrogance)...and when it's tried at nearly all levels to
hide these corruption bugs away behind duplicates or lesser severities..

So,... bringing this up here at d-d, as I think it would be good for
Debian to have a well thought position in how to handle this family of
corruption bugs...

If it's agreed upon with upstreams/maintainers that it's ok to let
people live with them... fine for me...
If not, than the majority opinion might perhaps even convince the
maintainers to handle this with some higher severity :)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: