1 |
Hi Kevin. |
2 |
|
3 |
That is an interesting idea. So one could check about vulnerabilies |
4 |
solutions |
5 |
_before_ package installation. And better. This could give us a measure |
6 |
about |
7 |
how secure [think a little bit ahead] packages in portage tree are. |
8 |
|
9 |
Actually, there are some mechanisms to know what is the mean time |
10 |
corrections are |
11 |
provided when one look to portage's tree as a whole? |
12 |
|
13 |
I like this idea and would like to suggest two other variables |
14 |
|
15 |
SECURITY_CORRECTION_DATE |
16 |
SECURITY_DISCOVERY_DATE |
17 |
|
18 |
containing the date the correction was published on portage tree and |
19 |
the date the problem was post [may be in bugzilla] |
20 |
|
21 |
Let me go back and continue to read Security Project documentation. |
22 |
|
23 |
|
24 |
Regards, |
25 |
|
26 |
Daniel A. Avelino |
27 |
|
28 |
|
29 |
On Fri, Aug 26, 2011 at 3:08 PM, Kevin Bryan <bryank@××××××.edu> wrote: |
30 |
|
31 |
> -----BEGIN PGP SIGNED MESSAGE----- |
32 |
> Hash: SHA1 |
33 |
> |
34 |
> Although I like having the summary information about what the |
35 |
> vulnerability is, if I'm only reading them for packages I have |
36 |
> installed, then a reference of some kind would suffice. |
37 |
> |
38 |
> I'd be fine even if it was just a new variable in the .ebuild file that |
39 |
> somehow indicated which versions it was a fix for, reusing the syntax |
40 |
> for dependency checking. A reference to the CVE or gentoo bug reference |
41 |
> would be good, too: |
42 |
> |
43 |
> SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64" |
44 |
> SECURITY_REF="CVE:2010-2169 http://..." |
45 |
> SECURITY_BUG="343089" |
46 |
> SECURITY_IMPACT="remote" |
47 |
> |
48 |
> Then would be most of the work the committer needs to do is right there |
49 |
> in a file they are modifying anyway. |
50 |
> |
51 |
> The portage @security set could also look for and evaluate these tags, |
52 |
> instead of parsing the GLSA's. |
53 |
> |
54 |
> Note on the impact variable: make a few easy to understand tags: |
55 |
> local |
56 |
> remote |
57 |
> remote-user-assist |
58 |
> denial-of-service |
59 |
> ... |
60 |
> |
61 |
> - --Kevin |
62 |
> |
63 |
> |
64 |
> On Fri, Aug 26, 2011 at 07:06:35PM +0200, Christian Kauhaus wrote: |
65 |
> |
66 |
> > Am 26.08.2011 18:55, schrieb Alex Legler: |
67 |
> > > Compared to other distributions, our advisories have been rather |
68 |
> detailed with |
69 |
> > > lots of manually researched information. I'm not sure if we can keep up |
70 |
> this |
71 |
> > > very high standard with the limited manpower, but we'll try our best. |
72 |
> > |
73 |
> > I see the point. I think it would be an achievement over the current |
74 |
> situation |
75 |
> > (which is: no current GLSAs at all) to send out less detailed GLSAs. Even |
76 |
> > something short as: "$PACKAGE has vulnerabilities, they are fixed in |
77 |
> $VERSION, |
78 |
> > for details see $CVE" would be immensely helpful. |
79 |
> > |
80 |
> > Is the any viable way to get it at least to this point? Probably the |
81 |
> largest |
82 |
> > part of such a task could be automated. This would lift the burden from |
83 |
> the |
84 |
> > security maintainers. |
85 |
> > |
86 |
> > Regards |
87 |
> > |
88 |
> > Christian |
89 |
> > |
90 |
> -----BEGIN PGP SIGNATURE----- |
91 |
> Version: GnuPG v2.0.18 (GNU/Linux) |
92 |
> |
93 |
> iEYEARECAAYFAk5X4SYACgkQ6ENyPMTUmzpTLwCeIrikkC82ZC/YMALUD3AUOG71 |
94 |
> GQ0An02FoagrOJSU4kFQ8RUP+q/1+zQn |
95 |
> =/kf5 |
96 |
> -----END PGP SIGNATURE----- |
97 |
> |
98 |
> |