[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The harden-*flaws packages.


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.


// 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: