> On 10 Nov 2022, at 08:43, Jaco Kroon <j...@uls.co.za> wrote: > > 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. >
I can't promise anything but if we've got fewer (IMO) useless/noisy fields, we can try put a bit more effort into these. But it's a good idea to actually explicitly ask maintainers for suggestions in security bugs! > 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. > 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. 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+? > > 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.
signature.asc
Description: Message signed with OpenPGP
