On Friday 26 August 2011 14:08:38 Kevin Bryan wrote: > Although I like having the summary information about what the > vulnerability is, if I'm only reading them for packages I have > installed, then a reference of some kind would suffice. > > I'd be fine even if it was just a new variable in the .ebuild file that > somehow indicated which versions it was a fix for, reusing the syntax > for dependency checking. A reference to the CVE or gentoo bug reference > would be good, too: > > SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64" > SECURITY_REF="CVE:2010-2169 http://..."; > SECURITY_BUG="343089" > SECURITY_IMPACT="remote" > > Then would be most of the work the committer needs to do is right there > in a file they are modifying anyway. > > The portage @security set could also look for and evaluate these tags, > instead of parsing the GLSA's.
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 <a...@gentoo.org> Gentoo Security / Ruby
signature.asc
Description: This is a digitally signed message part.
