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 20:42:18
Message-Id: CAKdB2xFFnTTK_GwOHBkwckHj4TfQ9jTf2nWHy7BiT4CUM6S_Pg@mail.gmail.com
In Reply to: Re: [gentoo-security] No GLSA since January?!? by Kevin Bryan
1 I like this approach but I have no idea about how this could be performed.
2
3 ACCEPT_RISKS="remote dos" emerge ...
4
5 Sounds very cool to me.
6
7 Daniel
8
9 On 8/26/11, Kevin Bryan <bryank@××××××.edu> wrote:
10 > -----BEGIN PGP SIGNED MESSAGE-----
11 > Hash: SHA1
12 >
13 > I was not considering the entire process, just the part that really
14 > impacts me: identifying vulnerable and patched packages. Full
15 > advisories are nice, but really what I want to know is when I need to
16 > update a particular package.
17 >
18 > You are right that marking the packages that contain fixes doesn't
19 > really scale because of increased baggage to carry forward.
20 >
21 > The problem I have with GLSA's is that they don't come out until after
22 > the problem has been fixed.
23 >
24 > Perhaps it would be better to just have a system to label a particular
25 > ebuild/version as vulnerable. Maybe something closer to package.mask,
26 > but for security would be appropriate. With a package.security_mask,
27 > you could have anyone on the security project update that file with
28 > packages as soon as they know about it and while they are waiting on the
29 > devs to fix it. References/links/impact could be noted in the comments
30 > above, as package.mask does now.
31 >
32 > As for interacting with 'emerge', I don't think we want the same
33 > semantics as package.mask, since we don't want to force a downgrade (if
34 > possible). It should probably just warn when you ask it to install a
35 > vulnerable version. Upgrades to safe versions will be quiet that way.
36 > The @security would contain packages with and without fixes so you get
37 > warnings for things that remain vulnerable, and updates for things that
38 > are fixed.
39 >
40 > Thoughts?
41 >
42 > - --Kevin
43 >
44 > On Fri, Aug 26, 2011 at 08:40:29PM +0200, Alex Legler wrote:
45 >>
46 >> A complete change of the system is very unlikely.
47 >> Nevertheless: What is the end-to-end process in your solution? (i.e.
48 >> vulnerability report to 'advisory' release)
49 >>
50 >> A while ago a similar solution was proposed. Basically you want to shift
51 >> our
52 >> job back to the package maintainers. That might work, but rais a few new
53 >> issues.
54 >>
55 >> We'd automatically lose some consistency, because not everyone would
56 >> follow
57 >> the needed or wanted data scheme. Such a thing is much better to control
58 >> in a
59 >> smaller and better connected group of people.
60 >>
61 >> Also, cleanup and large amounts of issues in packages are issues. Browsers
62 >>
63 >> usually get hundreds of CVEs assigned in a year, that would be all in the
64 >> Ebuild, and for how long?
65 >>
66 >> Personally, I'm not convinced this is a model that would be an improvement
67 >>
68 >> over the current situation.
69 >>
70 >> Alex
71 >>
72 >> --
73 >> Alex Legler <a3li@g.o>
74 >> Gentoo Security / Ruby
75 >
76 >
77 > -----BEGIN PGP SIGNATURE-----
78 > Version: GnuPG v2.0.18 (GNU/Linux)
79 >
80 > iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd
81 > VakAnA4yzElckmCZaikTsPZdWZU5VazF
82 > =MSwi
83 > -----END PGP SIGNATURE-----
84 >
85 >