But Alex, this could be a great improvement in system at all. This can help administrators to measure better its systems, and may be "force" developers to solve issues faster.
What do you think? Daniel On 8/26/11, Alex Legler <a...@gentoo.org> wrote: > 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