Hi,
On 2022/11/10 06:13, John Helmert III wrote:
- 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...
Actually yes! Also a way to check whether my specific configuration is
vulnerable for this specific CVE, something like "If you're setting
foo=bar in /etc/pkg.conf your system is vulnerable, if you've got
foo=phew you're most likely fine". Obviously we could rely a bit more
on package maintainers (myself included) to provide these.
I don't think I've seen a single "workaround" and usually the text here
just says "No known workaround", where the reality is that for something
like asterisk just not using the affected module is good enough. So
workaround: "Don't use chan_sip, use chan_pjsip instead" would be
perfectly fine here.
One could thus also link GLSA issues to specific USE flags, taking
asterisk again, let's say the problem is with the http web server having
a buffer overflow in the http basic authenticator, then if that embedded
server isn't even compiled in, how can the package be vulnerable? So
here vulnerable would be something like
<net-misc/asterisk-16.X.Y:16[http], <net-misc/asterisk-18.A.B[http],
which then also indicates the "fixed" versions, as has been pointed out
"affected" and "not affected" are inverses.
A mechanism to QUERY which installed packages are affected by known
GLSA's would also be tremendously helpful.
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.
Of course giving the full details in the GLSA is a pain in the backside,
is there a way to retrieve this information automatically from the CVE
database? In other words, just get the blurp from there and include it
here. It won't give full details, but at least it will give some extra
details not currently available. Effectively we choose to ignore
certain GLSAs if we consider their impact to be low.
It would also help a great deal to automate that if the CVE scores and
the "inputs" into that could be made available, eg, CVE score 7.0,
remote=yes/no, .... (And I'm fairly certain importing this from the CVE
database should be possible).
Of course, someone has to do the work, and the current status quo
doesn't irritate me enough to free up cycles to fix it, but if the above
could be (partially) accommodated that would be really, really great, if
not, no harm done.
Much appreciate that there is work being done in this area.
Kind Regards,
Jaco
