Re: Why back-porting patches to stable instead of releasing a new package.
On Sat, Aug 16, 2003 at 03:50:01PM -0400, Matt Zimmerman wrote:
> On Sat, Aug 16, 2003 at 12:45:20PM -0400, Andrew Pimlott wrote:
>
> > On Sat, Aug 16, 2003 at 11:05:02AM -0400, Matt Zimmerman wrote:
> > > One bug was fixed accidentally in a code reorganization. The
> > > old code was simply replaced with something else which
> > > happened not to have the bug. The other was fixed because it
> > > was a bug, but the security impact was not realized until
> > > later. This happens sometimes.
> >
> > I estimate that this happens often.
>
> Based on what? Certainly, any code which is removed may have bugs, and code
> is removed all the time in favour of new code. New code also introduces
> bugs. New code is not a security feature, in fact quite the opposite.
I was referring to the latter case: "fixed because it was a bug, but
the security impact was not realized until later". No, it's not
based on any statistics, but it would be a good subject for a
survey.
I wasn't talking about code reorganization or other large-scale
changes.
> > Make it easier to get bug-fixes into stable in a timely fashion. If you
> > have a system where bug-fixes have a "smooth" route into stable, the
> > security bugs get fixed along with them.
>
> If you want the point release process to be faster, then I suggest that you
> volunteer to help review uploads to proposed-updates.
My understanding of point releases is that, historically, they have
only included "critical problems or security updates"[1]. If that
is correct, then point releases don't help the problem I'm talking
about.
I'm thinking of something very much like current security updates,
only for bugs that may or may not be security-related. I'm not sure
exactly what level of review is needed--maybe we could start out
with no formal review (only guidelines for what changes are
appropriate), let users choose to try it, and see what happens.
> > If you have a "security-fixes-only" policy[...]
>
> We don't.
For all practical purposes, yes we do. For most stable users,
security fixes come two orders of magnitude faster than any other
bug fixes, and even then, only "critical" bug fixes.
> > I admit, I don't know for sure how well this works because I haven't
> > seen it in action.
>
> Subscribe to bugtraq, full-disclosure, debian-security-announce, etc. for a
> front-row seat.
We're not communicating, although I confess I was being a bit
facetious. I was imagining an oracle to which Debian maintainers
could submit changes, and get a response: exploitable or not
exploitable. Even if such a thing existed, it wouldn't solve the
problem because maintainers wouldn't always know which changes to
submit. Point being (call it the OpenBSD hypothesis, in spite of
your interpretation of their motives ;-) ), there exists no reliable
method for separating security bugs from other bugs.
> Maintainers often do not care in the least about security, or at least do
> not notice it. Upstream security fixes will be uploaded to unstable without
> checking whether stable needs to be fixed, or even mentioning the fact in
> the changelog in some obvious way, sometimes even if the maintainer knows
> about it.
Ok, since you agree about this, let me use it as a reference for
restating my point: Security fixes get made upstream that, for
whatever reason, don't get into stable (in a remotely timely
fashion). I argue that these holes put Debian users at greater risk
than is generally appreciated, and that the only way to reduce such
risks is to install bug fixes into stable on a timescale similar to
that for security fixes. If this is true, then an argument like
"the volume of such changes would be far too much for a stable
distribution" isn't really relevant. If the security win is big
enough, then people will put up with more churn and potential for
breakage.
Andrew
[1] http://www.debian.org/releases/stable/errata
Reply to: