-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. Note on the impact variable: make a few easy to understand tags: local remote remote-user-assist denial-of-service ... - --Kevin On Fri, Aug 26, 2011 at 07:06:35PM +0200, Christian Kauhaus wrote: > Am 26.08.2011 18:55, schrieb Alex Legler: > > Compared to other distributions, our advisories have been rather detailed > > with > > lots of manually researched information. I'm not sure if we can keep up this > > very high standard with the limited manpower, but we'll try our best. > > I see the point. I think it would be an achievement over the current > situation > (which is: no current GLSAs at all) to send out less detailed GLSAs. Even > something short as: "$PACKAGE has vulnerabilities, they are fixed in > $VERSION, > for details see $CVE" would be immensely helpful. > > Is the any viable way to get it at least to this point? Probably the largest > part of such a task could be automated. This would lift the burden from the > security maintainers. > > Regards > > Christian > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk5X4SYACgkQ6ENyPMTUmzpTLwCeIrikkC82ZC/YMALUD3AUOG71 GQ0An02FoagrOJSU4kFQ8RUP+q/1+zQn =/kf5 -----END PGP SIGNATURE-----
