Re: Why back-porting patches to stable instead of releasing a new package.
On Sat, Aug 16, 2003 at 09:42:33AM -0400, Andrew Pimlott wrote:
> The article discusses this advisory:
>
> http://lwn.net/Articles/42452/
>
> Both problems apparently were fixed some time ago upstream.
Wietse Venema explains what actually happened here:
http://www.securityfocus.com/archive/1/332000
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 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?
> http://lwn.net/Articles/44409/
>
> The first comment makes the point,
>
> That's why OpenBSD doesn't announce security holes they find
> when they fix bugs in inherited packages.
>
> Debian isn't OpenBSD, but I think most would agree that OpenBSD has
> a good understanding of the problem.
And we've had this argument with OpenBSD before (on this very mailing list).
They expect everyone to poll their CVS, and refused to make even the minimal
effort of tagging the commit message with an identifier that we could scan
for if we were interested in potential security fixes.
The real reason that OpenBSD doesn't like to announce things is that it
hurts their reputation. They market their distribution with claims such as
"Only one remote hole in the default install, in more than 7
years!"[www.openbsd.org], so if they do find bugs, it is to their advantage
not to talk about it, especially not to help other distributions.
> > Responsible Upstreams will publicize security holes, especially the
> > easily exploitable ones.
>
> Is Postfix (the subject of the above link) responsible? The upstream of
> the bug I know about is also generally considered responsible. When you
> fix a lot of bugs, it takes a lot of time to check every one for
> exploitability. Whether you think upstreams should check or not, it's
> almost impossible for them to do a perfect (or even close to perfect) job.
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. Look at the recent Apache problems for
example. After looking at them, we do not feel that they are serious enough
to warrant fixing in Debian stable, but nonetheless, the Apache developers
announced their existence and gave us the notification that we needed in
order to make an informed decision.
> > If it's in the Changelog, it would be the Debian package maintainer's
> > task to find it and see that it gets a security fix.
>
> It's harder than it sounds.
It's really pretty easy to read over the upstream changelog for a new
release. I do it for all of my packages, and it's a good practice
regardless of the potential for finding unannounced security problems.
> 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 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.
> This is an obvious trade-off, but it is manageable. Ideally, updates
> should come from a feature-frozen branch. If upstream doesn't have one,
> they should be persuaded, or distributions should create one. A
> well-controlled bug-fix-only branch is very reliable.
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.
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".
--
- mdz
Reply to: