1 |
On Thu, Nov 10, 2022 at 04:43:01AM +0100, Michał Górny wrote: |
2 |
> On Wed, 2022-11-09 at 20:27 -0600, John Helmert III wrote: |
3 |
> > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of |
4 |
> > October 2003. It used roughly the same format of the GLSAs we release |
5 |
> > today, in 2022, making that format almost as old as me. |
6 |
> > |
7 |
> > Somewhere along the way, it started to become necessary to target |
8 |
> > multiple version ranges within the same package. The GLSA format |
9 |
> > isn't capable of expressing this. Thus, I propose a new format (an |
10 |
> > example of which I've attached inline below), with the following |
11 |
> > changes from the old format: |
12 |
> > |
13 |
> > - Rework affected to use XML-ified logical operators to specify the |
14 |
> > affected versions, and *don't* use different fields to specify |
15 |
> > vulnerable and unaffected versions. Instead, only list vulnerable |
16 |
> > versions, unaffected versions are implicit. |
17 |
> |
18 |
> Does that imply op="" will now be limited to the standard ebuild |
19 |
> operators? Perhaps it'd be cleaner to take a step further and remove |
20 |
> the attribute in favor of going 100% ebuild syntax (yeah, escaping is |
21 |
> gonna suck there). |
22 |
|
23 |
The added complexity of escaping is exactly what I wanted to avoid! |
24 |
These are already enumerated in the old glsa.dtd [1] for usage in a |
25 |
similar way: |
26 |
|
27 |
<!ATTLIST vulnerable range (le|lt|eq|gt|ge|rlt|rle|rgt|rge) #REQUIRED |
28 |
|
29 |
[1] https://gitweb.gentoo.org/data/dtd.git/tree/glsa.dtd#n126 |
30 |
|
31 |
> > |
32 |
> > - Drop synopsis and description fields. These fields contain the same |
33 |
> > information and will be superceded by the existing impact field. |
34 |
> |
35 |
> Well, I'm not saying "no" but it feels a bit weird reading a GLSA that |
36 |
> doesn't say a word what the problem is but specifies impact. |
37 |
|
38 |
You're right, but with 19 CVEs (for example), is anyone really |
39 |
interested in hearing about the problem that caused each of the 19 |
40 |
issues? In the current format we've resorted to writing descriptions |
41 |
like... |
42 |
|
43 |
Multiple vulnerabilities have been discovered in $PACKAGE. Please |
44 |
review the CVE identifiers referenced below for details. |
45 |
|
46 |
... simply because it's infeasible (and in my opinion, not really |
47 |
necessary) for us to enumerate the issues in this way. Also, I note |
48 |
that the section being called "impact" doesn't preclude us from |
49 |
incorporating text that we would currently put in the "description" or |
50 |
"synopsis" fields. |
51 |
|
52 |
> BTW have you considered switching to JSON or TOML? ;-) |
53 |
|
54 |
Definitely! But that adds significantly more complexity to |
55 |
implementing this, and given I'm likely to be the only one working on |
56 |
it, I decided against trying it. If I were inventing GLSAs for the |
57 |
first time I'd definitely avoid XML, of course. |
58 |
|
59 |
> |
60 |
> -- |
61 |
> Best regards, |
62 |
> Michał Górny |
63 |
> |
64 |
> |