Hi Kevin.<br><br>That is an interesting idea. So one could check about vulnerabilies solutions<br>_before_ package installation. And better. This could give us a measure about <br>how secure [think a little bit ahead] packages in portage tree are. <br>
<br>Actually, there are some mechanisms to know what is the mean time corrections are <br>provided when one look to portage&#39;s tree as a whole?<br><br>I like this idea and would like to suggest two other variables <br>
<br>SECURITY_CORRECTION_DATE<br>SECURITY_DISCOVERY_DATE<br><br>containing the date the correction was published on portage tree and<br>the date the problem was post [may be in bugzilla]<br><br>Let me go back and continue to read Security Project documentation.<br>
<br><br>Regards,<br><br>Daniel A. Avelino<br><br><br><div class="gmail_quote">On Fri, Aug 26, 2011 at 3:08 PM, Kevin Bryan <span dir="ltr">&lt;<a href="mailto:bryank@...">bryank@...</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Although I like having the summary information about what the<br>
vulnerability is, if I&#39;m only reading them for packages I have<br>
installed, then a reference of some kind would suffice.<br>
<br>
I&#39;d be fine even if it was just a new variable in the .ebuild file that<br>
somehow indicated which versions it was a fix for, reusing the syntax<br>
for dependency checking.  A reference to the CVE or gentoo bug reference<br>
would be good, too:<br>
<br>
SECURITY_FIXES=&quot;&lt;www-plugins/adobe-flash-10.1.102.64&quot;<br>
SECURITY_REF=&quot;CVE:2010-2169 http://...&quot;<br>
SECURITY_BUG=&quot;343089&quot;<br>
SECURITY_IMPACT=&quot;remote&quot;<br>
<br>
Then would be most of the work the committer needs to do is right there<br>
in a file they are modifying anyway.<br>
<br>
The portage @security set could also look for and evaluate these tags,<br>
instead of parsing the GLSA&#39;s.<br>
<br>
Note on the impact variable: make a few easy to understand tags:<br>
local<br>
remote<br>
remote-user-assist<br>
denial-of-service<br>
...<br>
<br>
- --Kevin<br>
<div class="im"><br>
<br>
On Fri, Aug 26, 2011 at 07:06:35PM +0200, Christian Kauhaus wrote:<br>
<br>
&gt; Am <a href="tel:26.08.2011%2018" value="+12608201118">26.08.2011 18</a>:55, schrieb Alex Legler:<br>
&gt; &gt; Compared to other distributions, our advisories have been rather detailed with<br>
&gt; &gt; lots of manually researched information. I&#39;m not sure if we can keep up this<br>
&gt; &gt; very high standard with the limited manpower, but we&#39;ll try our best.<br>
&gt;<br>
&gt; I see the point. I think it would be an achievement over the current situation<br>
&gt; (which is: no current GLSAs at all) to send out less detailed GLSAs. Even<br>
&gt; something short as: &quot;$PACKAGE has vulnerabilities, they are fixed in $VERSION,<br>
&gt; for details see $CVE&quot; would be immensely helpful.<br>
&gt;<br>
&gt; Is the any viable way to get it at least to this point? Probably the largest<br>
&gt; part of such a task could be automated. This would lift the burden from the<br>
&gt; security maintainers.<br>
&gt;<br>
&gt; Regards<br>
&gt;<br>
&gt; Christian<br>
&gt;<br>
</div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.18 (GNU/Linux)<br>
<br>
iEYEARECAAYFAk5X4SYACgkQ6ENyPMTUmzpTLwCeIrikkC82ZC/YMALUD3AUOG71<br>
GQ0An02FoagrOJSU4kFQ8RUP+q/1+zQn<br>
=/kf5<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br>