Gentoo Archives: gentoo-security

From: Alex Legler <a3li@g.o>
To: gentoo-security@l.g.o
Cc: phajdan.jr@g.o
Subject: Re: [gentoo-security] Soliciting feedback for the GLSA-2 format
Date: Thu, 09 Jan 2014 15:08:58
Message-Id: 52CEBB55.9030809@gentoo.org
In Reply to: [gentoo-security] Soliciting feedback for the GLSA-2 format by Alex Legler
1 Forwarding from a private reply.
2
3 >> Now that we've been growing a bit in numbers and have managed to get the
4 >> GLSA circulation back on track, it is time to finally talk about the new
5 >> GLSA format that has been planned for quite a while.
6 >
7 > Yay, very exciting!
8 >
9 >> - Packages section reworked: While adding Slot support we tried to get a
10 >> new, simple, range-based scheme for marking vulnerable versions. The
11 >> flexibility the range operators offered before was hardly ever used
12 >> (mostly just to work around the lacking Slot support). We'd especially
13 >> like feedback in this area, I fear we might be missing some
14 >> functionality here. Quick explanation:
15 >> <package name="dev-lang/python">
16 >> <vulnerable slot="3.2" fixed="3.2.9"/>
17 >> <vulnerable slot="3.3" asof="3.3.0" fixed="3.3.1"/>
18 >> <vulnerable slot="3.3" asof="3.3.3" fixed="3.3.5"/>
19 >> <vulnerable slot="0" fixed="6.3"/>
20 >> </package>
21 >> <package name="dev-lang/python" arch="hppa">
22 >> <vulnerable/>
23 >> </package>
24 >>
25 >> Reads as follows:
26 >> On hppa, there is no fixed version.
27 >> On all other arches, python in slot 3.2 is fixed in >=3.2.9, affected
28 >> for anything less, in the 3.3 slot, [3.3.0; 3.3.1[ and [3.3.3; 3.3.5[
29 >> are affected, for the 0 slot, anything <6.3 is affected.
30 >
31 > Some thoughts:
32 >
33 > 1. It'd be great to see some pseudo-code algorithm for processing this.
34 >
35
36 If anyone finds the time, I'd rather have a verbatim definition and a
37 working reference implementation.
38
39 > 2. I'd prefer to avoid embedding too much knowledge of how dependencies
40 > work into GLSA (which is then subject to change as PMS changes). One
41 > crazy example would be vulnerability existing only when a certain USE
42 > flag is enabled, which currently cannot be expressed in GLSA and I don't
43 > know if it'd be useful/desirable (certainly not if GLSA syntax would
44 > need to change IMHO).
45
46 There are no plans to add any more dependency features.
47
48 >
49 > 3. Please consider just using portage atoms syntax, e.g.
50 >
51 > <vulnerable package="<dev-lang/python-3.2.9:3.2" />
52 > <vulnerable package="<dev-lang/python-3.3.5:3.3" />
53 > <vulnerable package="<dev-lang/python-6.3:0" />
54 > <vulnerable package="dev-lang/python" arch="hppa" />
55 >
56 > Then the set of vulnerable packages is a union of all matching atoms.
57 >
58 > Note that the above cannot encode that 3.3.1 is not vulnerable. I
59 > consider that an OK compromise for more simplicity.
60
61 1. This combines multiple attributes (package, version, slot,
62 comparator) into one field. That's something we've explicitly tried to
63 avoid when putting together an XML format.
64
65 2. We need exclusion of previous versions. Example: Package has no
66 slots, 1.x versions are unaffected, 2.x is affected and fixed in 2.1.
67 The 1.x versions need to be declarable as not vulnerable.
68
69 >
70 >> - Human-readable texts reworked: Background + Description + Resolution
71 >> instead of (Synopsis) + Background + Description + Impact + Resolution.
72 >>
73 >> - References reworked: Bugs moved into that tag, CVEs get their own tag
74 >> without a link that could break, other references go as <url>
75 >
76 > These are all awesome, glad to see that.
77 >
78 > Why not go further and even remove background? That can be taken from
79 > package description.
80
81 We thought about that. The problem is that ebuild descriptions are
82 non-uniform. That looks bad.
83
84 >
85 > I'm also thinking about title. Since it's going to contain package
86 > name(s) and "multiple vulnerabilities" most of the time, yet needs to be
87 > manually edited by a developer, it allows for inconsistencies and just
88 > makes editing/drafting harder (one needs to think what to put there).
89 > Why not just drop it from the XML and use list of packages and date for
90 > display or something similar?
91
92 There are templates for the title in our drafting software.
93 I feel like there's no gain in removing this.
94
95 >
96 >> - Metadata: Mostly leftovers from GLSAMaker v1 removed; We now list the
97 >> author as well as people reviewing a draft and signing off on it with a
98 >> proper name. Dates are in a standardized format.
99 >
100 > All sounds good.
101 >
102 > PaweĊ‚
103 >
104 >