| 1 |
Hi, |
| 2 |
|
| 3 |
On 2022/11/10 06:13, John Helmert III wrote: |
| 4 |
>>> - Drop synopsis and description fields. These fields contain the same |
| 5 |
>>> information and will be superceded by the existing impact field. |
| 6 |
>> Well, I'm not saying "no" but it feels a bit weird reading a GLSA that |
| 7 |
>> doesn't say a word what the problem is but specifies impact. |
| 8 |
> You're right, but with 19 CVEs (for example), is anyone really |
| 9 |
> interested in hearing about the problem that caused each of the 19 |
| 10 |
> issues? In the current format we've resorted to writing descriptions |
| 11 |
> like... |
| 12 |
Actually yes! Also a way to check whether my specific configuration is |
| 13 |
vulnerable for this specific CVE, something like "If you're setting |
| 14 |
foo=bar in /etc/pkg.conf your system is vulnerable, if you've got |
| 15 |
foo=phew you're most likely fine". Obviously we could rely a bit more |
| 16 |
on package maintainers (myself included) to provide these. |
| 17 |
|
| 18 |
I don't think I've seen a single "workaround" and usually the text here |
| 19 |
just says "No known workaround", where the reality is that for something |
| 20 |
like asterisk just not using the affected module is good enough. So |
| 21 |
workaround: "Don't use chan_sip, use chan_pjsip instead" would be |
| 22 |
perfectly fine here. |
| 23 |
|
| 24 |
One could thus also link GLSA issues to specific USE flags, taking |
| 25 |
asterisk again, let's say the problem is with the http web server having |
| 26 |
a buffer overflow in the http basic authenticator, then if that embedded |
| 27 |
server isn't even compiled in, how can the package be vulnerable? So |
| 28 |
here vulnerable would be something like |
| 29 |
<net-misc/asterisk-16.X.Y:16[http], <net-misc/asterisk-18.A.B[http], |
| 30 |
which then also indicates the "fixed" versions, as has been pointed out |
| 31 |
"affected" and "not affected" are inverses. |
| 32 |
|
| 33 |
A mechanism to QUERY which installed packages are affected by known |
| 34 |
GLSA's would also be tremendously helpful. |
| 35 |
|
| 36 |
> |
| 37 |
> Multiple vulnerabilities have been discovered in $PACKAGE. Please |
| 38 |
> review the CVE identifiers referenced below for details. |
| 39 |
> |
| 40 |
> ... simply because it's infeasible (and in my opinion, not really |
| 41 |
> necessary) for us to enumerate the issues in this way. Also, I note |
| 42 |
> that the section being called "impact" doesn't preclude us from |
| 43 |
> incorporating text that we would currently put in the "description" or |
| 44 |
> "synopsis" fields. |
| 45 |
|
| 46 |
Of course giving the full details in the GLSA is a pain in the backside, |
| 47 |
is there a way to retrieve this information automatically from the CVE |
| 48 |
database? In other words, just get the blurp from there and include it |
| 49 |
here. It won't give full details, but at least it will give some extra |
| 50 |
details not currently available. Effectively we choose to ignore |
| 51 |
certain GLSAs if we consider their impact to be low. |
| 52 |
|
| 53 |
It would also help a great deal to automate that if the CVE scores and |
| 54 |
the "inputs" into that could be made available, eg, CVE score 7.0, |
| 55 |
remote=yes/no, .... (And I'm fairly certain importing this from the CVE |
| 56 |
database should be possible). |
| 57 |
|
| 58 |
Of course, someone has to do the work, and the current status quo |
| 59 |
doesn't irritate me enough to free up cycles to fix it, but if the above |
| 60 |
could be (partially) accommodated that would be really, really great, if |
| 61 |
not, no harm done. |
| 62 |
|
| 63 |
Much appreciate that there is work being done in this area. |
| 64 |
|
| 65 |
Kind Regards, |
| 66 |
Jaco |
Archives