| 1 |
> On 10 Nov 2022, at 03:43, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> On Wed, 2022-11-09 at 20:27 -0600, John Helmert III wrote: |
| 4 |
>> The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of |
| 5 |
>> October 2003. It used roughly the same format of the GLSAs we release |
| 6 |
>> today, in 2022, making that format almost as old as me. |
| 7 |
>> |
| 8 |
>> Somewhere along the way, it started to become necessary to target |
| 9 |
>> multiple version ranges within the same package. The GLSA format |
| 10 |
>> isn't capable of expressing this. Thus, I propose a new format (an |
| 11 |
>> example of which I've attached inline below), with the following |
| 12 |
>> changes from the old format: |
| 13 |
>> |
| 14 |
>> - Rework affected to use XML-ified logical operators to specify the |
| 15 |
>> affected versions, and *don't* use different fields to specify |
| 16 |
>> vulnerable and unaffected versions. Instead, only list vulnerable |
| 17 |
>> versions, unaffected versions are implicit. |
| 18 |
> |
| 19 |
> Does that imply op="" will now be limited to the standard ebuild |
| 20 |
> operators? Perhaps it'd be cleaner to take a step further and remove |
| 21 |
> the attribute in favor of going 100% ebuild syntax (yeah, escaping is |
| 22 |
> gonna suck there). |
| 23 |
> |
| 24 |
>> |
| 25 |
>> - Drop synopsis and description fields. These fields contain the same |
| 26 |
>> information and will be superceded by the existing impact field. |
| 27 |
> |
| 28 |
> Well, I'm not saying "no" but it feels a bit weird reading a GLSA that |
| 29 |
> doesn't say a word what the problem is but specifies impact. |
| 30 |
> |
| 31 |
|
| 32 |
I think we'd rename impact -> description but description would now |
| 33 |
be "description of the problem" and not "description of the package". |
Archives