| 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 |
> |
Archives