Re: Security fixes for mozilla and firefox in Sarge?
Michael Stone wrote:
IMO, if people really intend for the package to have no security support
in the long term then it should exist only in volatile. I think it is
dangerously irresponsible to ship software we do not intend to support.
Would we have to move Sarge's kernel packages to 'volatile' then? ;)
I think that the split that Ubuntu makes[0] between 'main' and
'universe' is a good idea. Of course, even they don't backport security
fixes all the time--they just went from mozilla-firefox 1.0.2 to 1.0.6
in main.
But back to Debian. The system we have at the moment is not working:
users are installing packages from the stable release, in the assumption
that the packages are supported; in reality these packages are not
getting updated. From a user's point of view, this assumption is
perfectly reasonable, especially given statements such as:
"Debian takes security very seriously. Most security problems brought
to our attention are corrected within 48 hours." [1]
It was easy to make such a promise back in 1997, but today Debian is
much larger. If the security team is unable to function[2] such that the
above statement still holds true, then either the statement, or the job
that the team does, must be changed.
One way to solve the problem would be to partition the archive into
supported and unsupported packages:
deb http://mirror/debian sarge main contrib non-free
deb http://mirror/debian sarge/unsupported main contrib non-free
The idea is to make sure that the a user who doesn't know just how
bone-grindingly hard the process of providing security updates is, will
only be presented with packages that are supported, unless he enables
the stable/unsupported repository himself--similar to how the default
configuration of Ubuntu only has 'main' enabled by default.
Such a setup would be better than providing a simple list of
supported/unsupported packages, IMO.
Another way to do it is more of a break with the way that Debian has
traditionally operated: allow new versions into 'unsupported'. This
would make 'unsupported' more like 'volatile', but perhaps with a policy
that allows only minor version updates. Two problems with this are that
there are no standards between different projects as to what constitutes
a minor update; and that you're still screwed when upstream announces
the end of support for the branch that 'unsupported' would be tracking
(e.g., mozilla-firefox-1.0.x).
Enough detail. I don't claim to know where on the scale of 'unsupported'
-> 'volatile' -> backports that Firefox and other such packages should
end up. I merely hope to raise awareness of the fact that the current
security mechanisms don't appear to be working, and to start a
discussion of what can be done about it.
[0] http://www.ubuntulinux.org/ubuntu/components
[1] http://www.debian.org/security/
[2] Wording this is difficult. I certainly don't mean to imply that the
security team is under-performing. I know they are only volunteers, and
that providing security updates is a damn hard job, especially when
upstream doesn't care to help backporting security fixes to 'obsolete'
versions of their software. :)
--
Sam Morris
http://robots.org.uk/
PGP key id 5EA01078
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
Reply to: