Hi Thanks for the arguing.
On Sun, Sep 01, 2002 at 09:22:56PM -0400, Daniel Martin wrote: > Martin Schulze <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 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 / ---------------------------------------------------------------