Re: Why back-porting patches to stable instead of releasing a new package.
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.
> I still don't understand what you are suggesting. Get rid of stable, so
> that everyone must use the very latest maintainer upload of every package?
> Push every maintainer upload which includes a new upstream release into
> stable?
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 have a
"security-fixes-only" policy, then someone has to identify the
security-related fixes. I argue that this inevitably results in
many non-obvious security fixes getting missed.
My main point is that the current system overlooks a large class of
security holes, and that these holes are relatively easy for the bad
guys to find by browsing changelogs. To improve this, one approach
is to tell everyone, "look harder for security fixes". I believe
this approach is not effective, and that a better approach is a
policy of fixing bugs in stable, even if they are not known to be
exploitable.
> You don't need to check a bug for exploitability to know that it has the
> potential for a security problem. You just flag it and inform everyone so
> that they can look for themselves.
I admit, I don't know for sure how well this works because I haven't
seen it in action. Who is everyone? The security team? Does the
security team promise that they will investigate every potential
hole and either issue an advisory, or determine definitively that
the bug is not exploitable? If so, great, you just need to make
sure every developer knows and takes advantage of this service for
every change they are not sure is benign.
I suspect the reality is not nearly that good. I wonder how many
maintainers even check adequately for potential security bugs. They
don't always stand out in upstream changelogs. A huge range of bugs
can be involved in an exploit. And it's practically axiomatic that
most programmers have a poor understanding of security issues.
> > If a Debian developer watches the Changelog and applies only "obvious" bug
> > fixes, and tells the security team, "there are probable some security
> > holes fixed in here", will they accept it? I think they should.
>
> I don't see what this has to do with the security team. If the maintainer
> builds a package containing changes that he doesn't understand, I wouldn't
> want it to bypass unstable and testing and be injected directly into stable.
It's possible to understand a change, and see that it is "obviously
correct", without fully examining its security implications.
> It certainly shouldn't be announced as a security update which users are
> encouraged to install. A security advisory which does not explain the
> user's exposure leaves them without the information they need to make a
> decision about the update.
It could be announced as a potential but unverified hole. Anyway,
this whole "decision" thing is overblown for 99% of users. As long
as Debian is careful with stable updates, they should be extremely
reliable, and most users shouldn't think twice about installing
them. I suppose the other 1% can do their own research. I think
the benefit in terms of holes closed outweighs the cost of more
numerous and less informative updates.
> Most projects have no need for multiple branches of development, and Debian
> would have no right to ask them to take on such a burden.
Perhaps, and perhaps it is too much to ask Debian developers to take
up the slack. In some cases, the program is stable enough that the
main branch will do. At any rate, when such a branch exists or the
Debian maintainer is willing to maintain it, we should take
advantage of it to get bug-fixes into stable.
> We already have a well-controlled bug-fix-only branch. It's called
> "stable", and the system for making changes to it is known as
> "proposed-updates".
Bug-fixes do not get into stable in a timely fashion.
proposed-updates is not known or not understood by most users.
AFAIK, there's no policy about what goes there, which limits its
usefulness. But maybe it could become part of the solution.
Andrew
Reply to: