Re: Why back-porting patches to stable instead of releasing a new package.
On Sat, Aug 16, 2003 at 09:34:20AM +0200, Thomas Viehmann wrote:
> Andrew Pimlott wrote:
> > On Wed, Jul 23, 2003 at 09:10:01AM -0400, Matt Zimmerman wrote:
> >
> >>- Security advisories and the associated packages should fix security
> >> vulnerabilities and nothing else.
> > Have you perhaps seen
> ...
> > ? I think it's a fairly convincing critique of this policy. I'm
> Chances are I never will, because I'm not going to subscribe anytime soon. You
> could at least allude to the major points you find that convincing.
Sorry, I completely forgot LWN is a closed site. I believe the link
will be freely available next Thursday. ISTR that Debian developers
have a subscription compliments of HP (?), in case you're a Debian
developer.
The article discusses this advisory:
http://lwn.net/Articles/42452/
Both problems apparently were fixed some time ago upstream.
The discussion following the article seems to be unrestricted:
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.
> > sure there are many security holes in woody that are fixed in the
> > latest stable upstream release.[1] Debian's policy assures that all
> > well-publicized bugs get patched, but that doesn't mean that others
> > don't slip through the cracks. A capable cracker targeting a Debian
> > stable system has a simple algorithm: browse upstream changelogs for
> > closed holes that weren't publicized.
> 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.
> 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. Besides, security isn't somewhere you
want to play the blame game. You just want to close the holes.
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.
> Also, random updates to new upstream versions will break all kinds of
> (rightfully) expected behavior,
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.
> > [1] Actually, I know of one about which I am communicating with the
> > maintainer.
> That's a fairly unconvincing empirical basis.
That's why it's a footnote, not part of the main text.
Andrew
Reply to: