Gentoo Archives: gentoo-security

From: "Daniel A. Avelino" <daavelino@×××××.com>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] No GLSA since January?!?
Date: Fri, 26 Aug 2011 20:42:18
In Reply to: Re: [gentoo-security] No GLSA since January?!? by Kevin Bryan
I like this approach but I have no idea about how this could be performed.

ACCEPT_RISKS="remote dos"  emerge ...

Sounds very cool to me.


On 8/26/11, Kevin Bryan <bryank@××××××.edu> wrote:
> -----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----- > >