1 |
On Friday 26 August 2011 14:08:38 Kevin Bryan wrote: |
2 |
> Although I like having the summary information about what the |
3 |
> vulnerability is, if I'm only reading them for packages I have |
4 |
> installed, then a reference of some kind would suffice. |
5 |
> |
6 |
> I'd be fine even if it was just a new variable in the .ebuild file that |
7 |
> somehow indicated which versions it was a fix for, reusing the syntax |
8 |
> for dependency checking. A reference to the CVE or gentoo bug reference |
9 |
> would be good, too: |
10 |
> |
11 |
> SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64" |
12 |
> SECURITY_REF="CVE:2010-2169 http://..." |
13 |
> SECURITY_BUG="343089" |
14 |
> SECURITY_IMPACT="remote" |
15 |
> |
16 |
> Then would be most of the work the committer needs to do is right there |
17 |
> in a file they are modifying anyway. |
18 |
> |
19 |
> The portage @security set could also look for and evaluate these tags, |
20 |
> instead of parsing the GLSA's. |
21 |
|
22 |
A complete change of the system is very unlikely. |
23 |
Nevertheless: What is the end-to-end process in your solution? (i.e. |
24 |
vulnerability report to 'advisory' release) |
25 |
|
26 |
A while ago a similar solution was proposed. Basically you want to shift our |
27 |
job back to the package maintainers. That might work, but rais a few new |
28 |
issues. |
29 |
|
30 |
We'd automatically lose some consistency, because not everyone would follow |
31 |
the needed or wanted data scheme. Such a thing is much better to control in a |
32 |
smaller and better connected group of people. |
33 |
|
34 |
Also, cleanup and large amounts of issues in packages are issues. Browsers |
35 |
usually get hundreds of CVEs assigned in a year, that would be all in the |
36 |
Ebuild, and for how long? |
37 |
|
38 |
Personally, I'm not convinced this is a model that would be an improvement |
39 |
over the current situation. |
40 |
|
41 |
Alex |
42 |
|
43 |
-- |
44 |
Alex Legler <a3li@g.o> |
45 |
Gentoo Security / Ruby |