Re: The harden-*flaws packages.
Martin Schulze <joey@infodrom.org> writes:
> Please see the thread summarized in <http://www.debian.org/News/weekly/2002/29/>:
>
> Policy for Woody Point-Releases. [4]Several [5]developers [6]would
> [7]like to add new packages and updates to their packages to the
> recently released stable distribution of Debian. Adding new packages
> and random updates to the stable distribution, however, would nullify
> the entire idea of having a stable release, Joey [8]explained. Hence,
> the same policy as before will be used for point-releases of woody.
Yes, but how does this apply to a package that does nothing but
conflict with existing packages? (As is the case with most of the
harden-* packages)
Agreed, _random_ updates would be a bad thing. However, what the
maintainer is proposing here is updates that are driven by DSAs.
Although I find it a slight stretch, one could easily argue that the
updates to the harden-*flaws packages are security updates.
These updates share another feature with security updates. Imagine
the package netostrich, which helps you bury your head in the sand
remotely. Now, suppose the upstream authors discover a flaw in the
2.0 series of netostrich prior to version 2.33 which allows random
network users to bury other people's heads in the sand. Sarge soon
contains 2.34 with the security fix, yet woody contains 2.29.1 with a
backported fix. Then there would similarly need to be two
harden-remoteflaws; one for woody, which conflicts with netostrich
prior to 2.29.1, and one for sarge, which conflicts with netostrich
prior to 2.34. The harden-*flaws update has to be backported along
with the backported fix to netostrich.
Now, if we want the harden-remoteflaws package to be at all useful, it
needs to be updated along with DSAs...
Hrm. The more I think about this the more I wonder if maybe the
harden-*flaws packages make much sense in stable at all. If someone
is apt-get'ing from security.debian.org, they're already replacing
vulnerable versions with fixed ones. If someone is updating from a
point release CD, the same thing applies. The only case where I can
see it making sense is with someone following testing with most of
their packages on hold (they really want a stable system, and only
upgrade a package when they need to). Am I missing a scenario?
Reply to: