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

Re: the right bug severity in case of data corruption

Hey Henrique.

On Sat, 2012-11-24 at 22:27 -0200, Henrique de Moraes Holschuh wrote:
> ...

> At least for postfix, I'd expect them to accept a patch for local(8) to
> not quote From lines as a config option,
First, I've never asked not to quote From_ lines at all, cause this
would really lead to massive mail corruption / phantom messages.
What I usually proposed was mboxrd, which quotes _all_ From_ lines and
not just some.

>  with the default being to keep
> the current behaviour (i.e. quote them).
But apart from this,... yes you're right, Wietse already said he would
probably accept such a patch, but with the default still exposing the
users to data corruption.

Which does of course not necessarily mean that anyone is writing such a
patch, though.

> Look, if it were severity critical, given how long this situation stands,
> we'd not have this thread and nobody would be doing this.
Well or just no one ever recognised it, or those who did decided for
themselves, they could live with it...

> In postfix' case, it is documented like all heck, for example (see local(8)
> manpage)
Quote? Actually I had talked about just that lack with Wietse, too, and
he didn't complain when I mentioned that there was no big fat hint in
local(8) about mboxo being used and it's vulnerability to corruption.

> and it can trivially be configured to use something else to
> deliver mail to mbox files (such as procmail, etc).
Of course, but from the postfix documentation, nothing AFAICS tells one
the need to use a 3rd party MDA, because postfix' own were broken.

> We [Debian] could deprecate anything that uses mboxo (mbox old) format as
> the native/preferred storage format, and configure our stuff where possible
> to never use mboxo by default.  That's about it.
That's what I've meant,... and therefore I suggested to add notice about
the issue in those places where the user are most likely to read it,
e.g. package description, README.Debian and depending how prone a
program is to it, perhaps even via some hack like a informing debconf
dialogue (though someone has indicated this might conflict the policy).
E.g. Thunderbird is so much more vulnerable to it (right now) than
Evolution (where at least current versions rarely use mbox, unless you
import or export mail)... so for it I'd have said the inevitable debconf
warning would be appropriate.

Further my suggestion was, to inform users (typically via NEWS.Debian)
even when the issue has been fixed already, like in getmail, what has
happened over years.
It's like when you have some scientific application which does wrong
calculations... it's not fair to just fix it and think everything's fine
now... one also has to tell people that all their previous data is
likely wrong.

btw: I've always thought it meant mbox original ;-)

>   But first, you need to get
> support for better mbox formats on the important stuff.
Well I guess you'll agree that this is not that easy and usually a duty
for upstream.
I personally, may try to invest some time into postfix, but after my
struggles with the Evolution and TB upstreams, I have little interest to
- sorry for the rude tone - fix their crap.
Especially as it seems, well at least for TB, that mbox import/export is
coded quite crude in awkwardly many places...

> We [users/developers] can write patches to teach important software to use
> something less retarded than mboxo by default, and pester upstream to take
> them.  Just complaining about it obviously won't help, since people don't
> see it as a problem at all.  You need to do _all_ the leg work, write the
> new functionality, and test the heck out of it before you can really expect
> upstream to accept the change.
I think you know from your own experience, that one usually already has
a big stack of projects where one is involved in... and that changes to
core places of bigger projects like Evolution/TB are usually not just an
hour of coding.

> > If not, than the majority opinion might perhaps even convince the
> > maintainers to handle this with some higher severity :)
> That's not how it works.  Someone needs to come up with *well tested*
> patches for everything worth fixing.  THEN you can ask for some sort of
> Debian-wide pressure to get rid of mboxo outside of extra/old-libs...
Again, I've never asked from the Debian maintainers to write patches...
My point was that we need reasonable warnings for our users, such as
mentioned above.
I guess such warnings are very easy to add for any maintainer, right?

And as long as those are not in place, my point was, that a high
severity is appropriate to give at least users with the widespread
apt-listbugs a chance to notice what's going on.


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

Reply to: