Re: The harden-*flaws packages.
Hi
Thanks for the arguing.
On Sun, Sep 01, 2002 at 09:22:56PM -0400, Daniel Martin wrote:
> 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...
Yes. Luckily I just saw someone that have written a script that checks
the DSA:s and tell the maintainer that he/she has a vulnerable package.
That is a good solution (best?). The problem is that the DSA is
not able to distinguish between local/remote/3rdparty flaws but
that is not always interesting.
> 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?
Yes. When you have a lot of own-compiled debs in an other archive
which can be more or less stable.
So my suggestion (which it probably will be) is that the harden-*flaws
package either contain that (or such a) script or depend on it.
Maybe I will merge the *flaws into a flaws package.
Regards,
// Ola
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: