Hi Sam,
On 2022/11/10 12:19, Sam James wrote:
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.
The problem with this is, there's a high cost associated with getting it wrong. A
"workaround" is accepted to have some level of fuzziness (we always try to be
accurate, but it's not the same as saying something is absolutely not vulnerable with
USE=-foo).
But I guess if a library totally isn't used then we can be sure sometimes. Not
sure now! I welcome more thoughts on this.
In the specific example I can most certainly make that assertion,
assuming of course I verify that the code is in fact in that library, as
you say. So if res_http in this case creates the buffer instead of
dynamically allocating it, or performing bounds checks, and not the
common digest code, then I can state that with 100% certainty. But yes,
this may or may not be a good idea, it's an idea/concept. Michał
suggested just using the ebuild syntax, which would imply this becomes
available.
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.
1. I really welcome your input here, as we're trying to figure out what people
actually want from GLSAs vs what is just noise for both them & us.
My pleasure. Really enjoy having these discussions.
2. I think this should be possible, but is it substantially more valuable than
doing the reference links like we do now? What if there's absolutely tonnes
like 20+?
Then I'd be following 20+ links :). I'd rather get that information in
one place, even if it is a longer read. Perhaps pointless to put this
in the GLSA XML structure, but glsa-check can perhaps just get an option
extra to -d to "retrieve and display CVE information additionally".
Re-use the -c that's currently used with -l. That way even with 20+
CVEs I can get glsa-check to fetch the information rather than having to
follow the links and decoding the usually cryptic information there on a
case-by-case basis. Or an option to pass the url's to a command, eg "-u
firefox" which will then execute "firefox ${url}" for every referenced URL.
-d and -l could perhaps learn to output xml and/or json and/or the other
format Michał mentioned.
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).
Yeah, we've talked about this before as well.
