Re: On Mozilla-* updates
Hi Martin,
thanks for raising this publically. Sorry, if I sound provocive here,
but this discussion has a history for me. As I said since several years,
the only practical way for Debian to stay up-to-date with Mozilla
security updates is to stay current with the latest "stable" release.
For Mozilla SeaMonkey, this means you shipped Mozilla 1.7.6 or whatever
was current with Sarge and by now already distribute Mozilla 1.7.11 debs
on security.debian.org.
Moz 1.7.11 was in cvs since a few days, so enough time to prepare ("a
few days" from patch to end-user is all you get in the security world,
and it's doable). It implies that you keep a close eye on what's
happening at mozilla.org - if you see the announcement at
www.mozilla.org, it's already too late. To faciliate cooperation, I have
invited the Debian security people to the Mozilla security team long
ago, with no result.
I personally maintain 1 or 2 browsers intended for the mass-market on
all platforms based on Mozilla 1.7, and the source code changes in the
releases were indeed very small, and close to (or at) the minimum
possible to fix the security holes. Updates were surprisingly painless.
In one case (1.7.7), they did break some functionality, but that was
inherent to the security update, because the "API" (a certain, obscure
way to use JavaScript in combination with the DOM) was insecure and I
don't think ever intended. As was visible on blogs, the mozilla security
was very much trying to find a solution that wouldn't break things. That
said, I had no problems at all with our code (although I expected lots).
What's more important, everything that *did* break most likely had
security hole itself, so arguably *should* break and not be used anymore.
So, basically, you can't *always* keep things running as they were and
still be secure. What comes to me, the tradeoff is clear: An insecure
system is completely unacceptable, and not usable *at all*. So given the
choice of some extensions breaking and having gapping security holes,
there's IMHO only one choice. What I'm getting at is that you *cannot*
maintain your stance of "we'll never break or change anything noticable
in a stable release for 3 years". If a user wants that, he should cut
all network connections and never update.
I'm speaking mainly about SeaMonkey, I can't speak about Firefox and
Thunderbird, esp. once they hit 1.5. What's hurting you in this case is
the ultra-long release cycle of Debian stable. The problem you are
*then* facing with backporting security fixes is the same that the
mozilla security team would face - very often, it's unjustifiably
time-consuming. As far as I know, caillon from and for Redhat (also a
Mozilla contributor) is doing that, or at least used to, with Mozilla
1.6. Maybe talk to him? But be prepared: this means real work.
But that's not the problem right now. What's wrong with just shipping
Firefox and Thunderbird 1.0.6? Frankly, that's what they are meant for.
The patches *are* backported from the trunk to 1.0.x for you. And using
a different version number only confuses users (who check their
vulnerability) and extensions.
Concretely, I don't understand what you base your introduction on:
it seems that less than two months after the release of sarge it is
not possible to support Mozilla, Thunderbird, Firefox ... packages
anymore. (in terms of fixing security related problems)
What hard reasons are there that prevent you from shipping Firefox 1.0.6
and Mozilla 1.7.11 right now?
In the end, though, you have to drop the idea of keeping the everything
as-is, no user-noticable changes, for 3 years. You have to lose your
current ideas and put security first. (I'm not including freedom etc.
here :-) .)
I am more than willing to help establish cooperation between Debian and
mozilla.org, if there's interest.
--
Ben Bucksch
If replying privately, please remove ".news".
Reply to: