Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-security
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-security@g.o
From: Kevin Bryan <bryank@...>
Subject: Re: No GLSA since January?!?
Date: Fri, 26 Aug 2011 16:02:56 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was not considering the entire process, just the part that really
impacts me: identifying vulnerable and patched packages.  Full
advisories are nice, but really what I want to know is when I need to
update a particular package.

You are right that marking the packages that contain fixes doesn't
really scale because of increased baggage to carry forward.

The problem I have with GLSA's is that they don't come out until after
the problem has been fixed.  

Perhaps it would be better to just have a system to label a particular
ebuild/version as vulnerable.  Maybe something closer to package.mask,
but for security would be appropriate.  With a package.security_mask,
you could have anyone on the security project update that file with
packages as soon as they know about it and while they are waiting on the
devs to fix it.  References/links/impact could be noted in the comments
above, as package.mask does now.

As for interacting with 'emerge', I don't think we want the same
semantics as package.mask, since we don't want to force a downgrade (if
possible).  It should probably just warn when you ask it to install a
vulnerable version.  Upgrades to safe versions will be quiet that way.
The @security would contain packages with and without fixes so you get
warnings for things that remain vulnerable, and updates for things that
are fixed.

Thoughts?

- --Kevin

On Fri, Aug 26, 2011 at 08:40:29PM +0200, Alex Legler wrote:
> 
> A complete change of the system is very unlikely.
> Nevertheless: What is the end-to-end process in your solution? (i.e. 
> vulnerability report to 'advisory' release)
> 
> A while ago a similar solution was proposed. Basically you want to shift our 
> job back to the package maintainers. That might work, but rais a few new 
> issues.
> 
> We'd automatically lose some consistency, because not everyone would follow 
> the needed or wanted data scheme. Such a thing is much better to control in a 
> smaller and better connected group of people.
> 
> Also, cleanup and large amounts of issues in packages are issues. Browsers 
> usually get hundreds of CVEs assigned in a year, that would be all in the 
> Ebuild, and for how long?
> 
> Personally, I'm not convinced this is a model that would be an improvement 
> over the current situation.
> 
> Alex
> 
> -- 
> Alex Legler <a3li@g.o>
> Gentoo Security / Ruby


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd
VakAnA4yzElckmCZaikTsPZdWZU5VazF
=MSwi
-----END PGP SIGNATURE-----


Replies:
Re: No GLSA since January?!?
-- Alex Legler
Re: No GLSA since January?!?
-- Daniel A. Avelino
References:
No GLSA since January?!?
-- Christian Kauhaus
Re: No GLSA since January?!?
-- Christian Kauhaus
Re: No GLSA since January?!?
-- Kevin Bryan
Re: No GLSA since January?!?
-- Alex Legler
Navigation:
Lists: gentoo-security: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: No GLSA since January?!?
Next by thread:
Re: No GLSA since January?!?
Previous by date:
Re: No GLSA since January?!?
Next by date:
Re: No GLSA since January?!?


Updated Oct 31, 2011

Summary: Archive of the gentoo-security mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.