Re: Why back-porting patches to stable instead of releasing a new package.
On Mon, Aug 18, 2003 at 09:33:07PM -0400, Andrew Pimlott wrote:
> On Sat, Aug 16, 2003 at 03:50:01PM -0400, Matt Zimmerman wrote:
> > 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.
What you propose does not sound at all different from a point release; you
are simply suggesting a change in the guidelines for what might be a
included in a point release.
> 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.
You could start collecting such updates from maintainers (perhaps via
proposed-updates) and make them available to users for testing, and see if
this works out well.
> > > 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.
Security fixes only come faster if the user chooses to add the corresponding
apt source. If they were to do the same thing for proposed-updates, they
would immediately receive any stable update proposed by any Debian
developer. However, the fact that many people don't do this (even among
those who are aware of proposed-updates) reflects a choice in favour of
stability.
> 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.
Security-related bugs are noticed, more often than not, if the person fixing
the bug is aware of basic security issues. Subtle bugs whose impact might
go unnoticed until later are much less common. Consider that if someone
reading changelogs or diffs can spot a bug with security impact, the person
who made the fix has a greater chance of doing so, if they have security in
mind.
I might venture so far as to say that it is more straightforward to tell,
for an arbitrary source code modification, whether a security-related bug is
present than whether the change is correct, or to separate bug fixes from
other changes. Of course, proper changelog entries from the maintainer can
correct both of those difficulties.
> 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.
The current process is such that updates to stable essentially bypass the
normal QA process of unstable and testing, where many users install and test
normal maintainer uploads. In order for this to be feasible, the changes
must be well-understood and not risk making the package worse rather than
better. In addition, the tangible benefit must outweigh the fundamental
risk inherent in changing the package.
If a change is not addressing a known bug which is affecting users of
stable, then that change is not, in my opinion, worth the risks. Pushing a
lot of unknown updates into stable in the hope of fixing unknown bugs cannot
possibly be a win. Users do not, in general, accept instability in exchange
for the mere potential for a fix for a bug that cannot be identified or
described (I certainly don't).
Therefore I submit these opinions:
- The potential benefit from "stealth" security bug fixes is not significant
- The instability and potential for problems introduced by churn in stable
is significant
- We should not encourage these "stealth" security bug fixes, because they
are both a disservice to the user community and make our job as
integrators more difficult
Anyone is, of course, free to prove me wrong by providing such updates for
stable, and showing that the result is an improved stable distribution.
--
- mdz
Reply to: