Hi Kevin. That is an interesting idea. So one could check about vulnerabilies solutions _before_ package installation. And better. This could give us a measure about how secure [think a little bit ahead] packages in portage tree are.
Actually, there are some mechanisms to know what is the mean time corrections are provided when one look to portage's tree as a whole? I like this idea and would like to suggest two other variables SECURITY_CORRECTION_DATE SECURITY_DISCOVERY_DATE containing the date the correction was published on portage tree and the date the problem was post [may be in bugzilla] Let me go back and continue to read Security Project documentation. Regards, Daniel A. Avelino On Fri, Aug 26, 2011 at 3:08 PM, Kevin Bryan <bry...@cs.uri.edu> wrote: > -----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----- > >
