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