-----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-----