Gentoo Archives: gentoo-security

From: "Daniel A. Avelino" <daavelino@×××××.com>
To: gentoo-security@l.g.o
Subject: Re: [gentoo-security] No GLSA since January?!?
Date: Fri, 26 Aug 2011 18:43:25
Message-Id: CAKdB2xHDCNRLnrY4M0Jpp8yzdixfWkYau2z-6YmSXKAH7Hhe1A@mail.gmail.com
In Reply to: Re: [gentoo-security] No GLSA since January?!? by Kevin Bryan
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 >