On Friday 26 August 2011 16:02:56 Kevin Bryan wrote: > 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?
I see this as an addition to sending advisories after fixing an issue, not as a solution to the issue at hand. -- Alex Legler <a...@gentoo.org> Gentoo Security / Ruby
signature.asc
Description: This is a digitally signed message part.
