Re: xulrunner 1.9.2 into sid?
On Wed, 30 Jun 2010 09:08:36 +0200 Mike Hommey wrote:
> > Disadvantages of maintaining the status quo:
> > - part way through the release, security support will end and many
> > users won't even notice (unless they're subscribed to
> > debian-security); leaving a lot of the Debian user base vulnerable.
> That surely can be arranged with a special security upload of the
> package displaying a message to the user in some way (which, IMHO,
> should be done with any package which security support is dropped)
I think that's a great solution.
> > Anyway, I hope I've done a better job of clearly defining the scope of
> > the problem. I look forward to some constructive debate.
> Your debate is pointless. Why do you care ? What is your agenda ? Do you
> want me to list the same kind of problems webkit gives ? IMHO, webkit
> gives more headaches than mozilla. Simply because despite all you can
> say, you have several codebases for each debian suite. Each of which may
> or may not have some of the security issues. This is in no way any
> better than with mozilla.
> As for access to the security bugs information, relying on the public
> information is not enough anyway if you want to provide *timely*
> security updates. The current webkit support in debian is waaaaay after
> the facts. The current mozilla support in debian is only a few days
> off, merely because the CVE and MFSA information is not available to me
> until upstream releases its security update.
> Also, speaking of upstream security support, I have yet to see an
> upstream "stable" release of webkit that includes security fixes. I
> don't remember there was any for the GTK port, despite a promise for
> some, and I don't think there was any for the QT port either.
> At least, Mozilla continues to support older releases for some months
> after a new major release. So far, that doesn't appear to have been
> true for webkit. Actually, apart from Chromium, I don't think there are
> releases with security fixes in webkit at all. And even then, I don't
> think Chromium upstream releases security fixes for older major
> The best you can do is actually to go through the CVEs and webkit
> security bugs, and find the relevant patches in svn, hoping they are not
> dependent on changes in the codebase between the moment it was fixed in
> svn, and the codebase you're trying to patch. And then, you have to
> account for the fact that you have several codebases in each debian
> suite. How exactly is that supposed to be better ? So, why exactly would
> we have to chose webkit over mozilla ? Because it's the new cool kid on
> the block ?
> Finally, the security team hasn't been involved in patching mozilla for
> years. AFAIK, patching is what makes most of the work in security
> support. Except this work is done by the mozilla maintainers and has
> been for a while. What exactly are you trying to get off the security
> team shoulders ? Handling a security build and issuing a DSA ? Following
> the advisories for mozilla ?
I completely concur. Webkit has some growing pains and poses its own
set of unique issues that need to be addressed; which I plan to work.
> All in all, will you just do something really constructive and stop this
> crusade of yours ?
As stated previously, my intent was simply to debate the consequences of
mozilla's new extremely short support timeframe; certainly no crusade,
and certainly no reason to turn the heat up.
Since you're content with the amount of work involved with security
backports, and as long as users are loudly informed when suppport gets
terminated, then all of my concerns are addressed. At this point I'm
perfectly content with the outcome. Thanks for taking the time to
resolve the issues.