Re: [gentoo-dev] [RFC] A new GLSA schema
CSAF is exactly what we want with GLSA. There are already many tools to parse and pretty print the CSAF documents. Thanks, I'll look into it more. Can you offer to help implement it in Portage? Not this year, but I can try to help. There are many ready to use tools around csaf already. You can also combine it with https://securitytxt.org/ Here is an example: https://www.bsi.bund.de/.well-known/security.txt The line CSAF: https://cert-bund.de/.well-known/csaf/provider-metadata.json tells where to find the csaf data. -- Best, Jonas
Re: [gentoo-dev] [RFC] A new GLSA schema
On Fri, 2022-11-11 at 16:06 -0600, Gordon Pettey wrote: > On Thu, Nov 10, 2022 at 6:27 PM John Helmert III wrote: > > > On Thu, Nov 10, 2022 at 09:49:27PM +0100, Jonas Stein wrote: > > > On 10/11/2022 03:27, John Helmert III wrote: > > > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > > > October 2003. It used roughly the same format of the GLSAs we release > > > > today, in 2022, making that format almost as old as me. > > > > > > IFF we change the format, we should not invent a new standard [1] but > > > use existing one like CSAF [2] > > > > > > [1] https://imgs.xkcd.com/comics/standards.png > > > [2] https://oasis-open.github.io/csaf-documentation/ > > > > We're not inventing a new "standard", we're upgrading the format we use > > to distribute GLSAs. > > > > Standard, format, semantics. You are producing a new schema in a field > where at least one usable (and already-improved?) schema exists. NIH? GLSA: 2003 CSAF: 2016 Sure sounds like OASIS did a NIH there. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] A new GLSA schema
> On 12 Nov 2022, at 00:04, Gordon Pettey wrote: > > On Fri, Nov 11, 2022 at 4:43 PM Sam James wrote: > > Oh I see, I'd missed the actual link to CSAF, sorry. > > I'll take a look. It's not clear to me yet if this is going to be a good > fit for distributions though, as we're not a normal "vendor". > > Are you aware of any other Linux distros using this? > > Red Hat has it in "beta": https://access.redhat.com/security/data, and has > had the prior OASIS format (CVRF) for a time, which they (Red Hat) will be > deprecating in 2023-01. There is also VEX, which is (I think, didn't read the > detailed spec) a subset of CSAF. Thanks, that's rather helpful. We'll look into this. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] A new GLSA schema
On Fri, Nov 11, 2022 at 4:43 PM Sam James wrote: > > Oh I see, I'd missed the actual link to CSAF, sorry. > > I'll take a look. It's not clear to me yet if this is going to be a good > fit for distributions though, as we're not a normal "vendor". > > Are you aware of any other Linux distros using this? > Red Hat has it in "beta": https://access.redhat.com/security/data, and has had the prior OASIS format (CVRF) for a time, which they (Red Hat) will be deprecating in 2023-01. There is also VEX, which is (I think, didn't read the detailed spec) a subset of CSAF.
Re: [gentoo-dev] [RFC] A new GLSA schema
> On 12 Nov 2022, at 00:01, Jonas Stein wrote: > > [2] https://oasis-open.github.io/csaf-documentation/ > >> Oh I see, I'd missed the actual link to CSAF, sorry. > > My fault. I should not add xkcd links in future. Nah, the xkcd is fine, I just missed the link to the actual standard. No worries. > >> I'll take a look. It's not clear to me yet if this is going to be a good >> fit for distributions though, as we're not a normal "vendor". > > The major idea of CSAF is to use it optionally along with CPE, CVE, > security.txt > These are fully compatible and complete each other. > > We are a "vendor" in this scheme. > You can find already CVEs assigned to the product with the CPE > cpe:2.3:a:gentoo: > That's a bit different because that's when there's a vulnerability in e.g. Portage, I think. > So we are the vendor "gentoo". > Perhaps gentoo_project would be more intuitive but currently it is "gentoo". > >> Are you aware of any other Linux distros using this? > > Langley Rock from Red Hat seems to be part of the editors team. > So I guess Redhat/Centos are on the way. > > (see https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html) > > Here are some presentations: > https://oasis-open.github.io/csaf-documentation/videos.html > > CSAF is exactly what we want with GLSA. > There are already many tools to parse and pretty print the CSAF documents. Thanks, I'll look into it more. Can you offer to help implement it in Portage? signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] A new GLSA schema
[2] https://oasis-open.github.io/csaf-documentation/ Oh I see, I'd missed the actual link to CSAF, sorry. My fault. I should not add xkcd links in future. I'll take a look. It's not clear to me yet if this is going to be a good fit for distributions though, as we're not a normal "vendor". The major idea of CSAF is to use it optionally along with CPE, CVE, security.txt These are fully compatible and complete each other. We are a "vendor" in this scheme. You can find already CVEs assigned to the product with the CPE cpe:2.3:a:gentoo: So we are the vendor "gentoo". Perhaps gentoo_project would be more intuitive but currently it is "gentoo". Are you aware of any other Linux distros using this? Langley Rock from Red Hat seems to be part of the editors team. So I guess Redhat/Centos are on the way. (see https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html) Here are some presentations: https://oasis-open.github.io/csaf-documentation/videos.html CSAF is exactly what we want with GLSA. There are already many tools to parse and pretty print the CSAF documents. -- Best, Jonas
Re: [gentoo-dev] [RFC] A new GLSA schema
> On 11 Nov 2022, at 22:40, Sam James wrote: > > > >> On 11 Nov 2022, at 22:06, Gordon Pettey wrote: >> >> On Thu, Nov 10, 2022 at 6:27 PM John Helmert III wrote: >> On Thu, Nov 10, 2022 at 09:49:27PM +0100, Jonas Stein wrote: >>> On 10/11/2022 03:27, John Helmert III wrote: The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of October 2003. It used roughly the same format of the GLSAs we release today, in 2022, making that format almost as old as me. >>> >>> IFF we change the format, we should not invent a new standard [1] but >>> use existing one like CSAF [2] >>> >>> [1] https://imgs.xkcd.com/comics/standards.png >>> [2] https://oasis-open.github.io/csaf-documentation/ >> >> We're not inventing a new "standard", we're upgrading the format we use >> to distribute GLSAs. >> >> Standard, format, semantics. You are producing a new schema in a field where >> at least one usable (and already-improved?) schema exists. NIH? > > Can you point to a format which would support using our ebuild operators > & syntax rather than making a (very) vague suggestion? > > See also ajak's point about being the one to implement it, in lieu > of volunteers. Oh I see, I'd missed the actual link to CSAF, sorry. I'll take a look. It's not clear to me yet if this is going to be a good fit for distributions though, as we're not a normal "vendor". Are you aware of any other Linux distros using this? signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] A new GLSA schema
> On 11 Nov 2022, at 22:06, Gordon Pettey wrote: > > On Thu, Nov 10, 2022 at 6:27 PM John Helmert III wrote: > On Thu, Nov 10, 2022 at 09:49:27PM +0100, Jonas Stein wrote: > > On 10/11/2022 03:27, John Helmert III wrote: > > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > > October 2003. It used roughly the same format of the GLSAs we release > > > today, in 2022, making that format almost as old as me. > > > > IFF we change the format, we should not invent a new standard [1] but > > use existing one like CSAF [2] > > > > [1] https://imgs.xkcd.com/comics/standards.png > > [2] https://oasis-open.github.io/csaf-documentation/ > > We're not inventing a new "standard", we're upgrading the format we use > to distribute GLSAs. > > Standard, format, semantics. You are producing a new schema in a field where > at least one usable (and already-improved?) schema exists. NIH? Can you point to a format which would support using our ebuild operators & syntax rather than making a (very) vague suggestion? See also ajak's point about being the one to implement it, in lieu of volunteers. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 6:27 PM John Helmert III wrote: > On Thu, Nov 10, 2022 at 09:49:27PM +0100, Jonas Stein wrote: > > On 10/11/2022 03:27, John Helmert III wrote: > > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > > October 2003. It used roughly the same format of the GLSAs we release > > > today, in 2022, making that format almost as old as me. > > > > IFF we change the format, we should not invent a new standard [1] but > > use existing one like CSAF [2] > > > > [1] https://imgs.xkcd.com/comics/standards.png > > [2] https://oasis-open.github.io/csaf-documentation/ > > We're not inventing a new "standard", we're upgrading the format we use > to distribute GLSAs. > Standard, format, semantics. You are producing a new schema in a field where at least one usable (and already-improved?) schema exists. NIH?
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 09:49:27PM +0100, Jonas Stein wrote: > On 10/11/2022 03:27, John Helmert III wrote: > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > October 2003. It used roughly the same format of the GLSAs we release > > today, in 2022, making that format almost as old as me. > > IFF we change the format, we should not invent a new standard [1] but > use existing one like CSAF [2] > > [1] https://imgs.xkcd.com/comics/standards.png > [2] https://oasis-open.github.io/csaf-documentation/ We're not inventing a new "standard", we're upgrading the format we use to distribute GLSAs. Besides, what would this actually mean for us? Are you volunteering to help implement a transition? > -- > Best, > Jonas > > signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 10:55:03PM +0200, Mart Raudsepp wrote: > Ühel kenal päeval, N, 10.11.2022 kell 22:07, kirjutas Jaco Kroon: > > > Like glsa-check? > > We currently use that, but it really just says which GLSAs are > > applicable to the system, it doesn't tell me net-misc/asterisk- > > 16.0.1:16 > > - we've got ways of working from the glsa-check output to that. Of > > particular annoyance if a GLSA lists multiple packages, of which you > > have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I > > can > > quite quickly determine that emerge -1av net-misc/asterisk:16 will > > resolve the problem with the lowest possible risk of breakage to > > other > > components on the system, and without having to perform a full > > update. > > emerge -vpO @security > > but to get something like it to only showing which installed asterisk > SLOT is vulnerable would be some extra coding with portage API I think. Yeah, to implement this, working on glsa-check is already necessary. I'm willing to look into ensuring the @security set works properly as well. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
Ühel kenal päeval, N, 10.11.2022 kell 22:07, kirjutas Jaco Kroon: > > Like glsa-check? > We currently use that, but it really just says which GLSAs are > applicable to the system, it doesn't tell me net-misc/asterisk- > 16.0.1:16 > - we've got ways of working from the glsa-check output to that. Of > particular annoyance if a GLSA lists multiple packages, of which you > have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I > can > quite quickly determine that emerge -1av net-misc/asterisk:16 will > resolve the problem with the lowest possible risk of breakage to > other > components on the system, and without having to perform a full > update. emerge -vpO @security but to get something like it to only showing which installed asterisk SLOT is vulnerable would be some extra coding with portage API I think.
Re: [gentoo-dev] [RFC] A new GLSA schema
On 10/11/2022 03:27, John Helmert III wrote: The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of October 2003. It used roughly the same format of the GLSAs we release today, in 2022, making that format almost as old as me. IFF we change the format, we should not invent a new standard [1] but use existing one like CSAF [2] [1] https://imgs.xkcd.com/comics/standards.png [2] https://oasis-open.github.io/csaf-documentation/ -- Best, Jonas
Re: [gentoo-dev] [RFC] A new GLSA schema
Hi, On 2022/11/10 16:24, John Helmert III wrote: On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon 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. That would greatly increase the care necessary for us to release a GLSA. It's already a big pain (even with the new GLSAMaker being a huge improvement over the old one), and I'd like to make it less of a pain. Maybe a proxy for this information for you would be the "type" field of the impact? Fair enough at pain. Limited people, limited resources. I do think that package maintainers should get involved in the process though, to help provide this information, but this should not cause delays in getting the GLSAs released. Even if the GLSA gets updated on a future iteration to add some of this information. What I'm after is being able to quickly decide (since we sometimes see a fair number of of GLSAs coming in around the same time, affecting different systems, with variable degrees of "exposedness" and need to be able to prioritise which systems to update first) whether we can (relatively) safely ignore a GLSA (at least temporarily). 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 The "atom" attribute of each constraint is using atom syntax, so along with that we get the ability to specify USE exactly like "asterisk-16.X.Y:16[http]". A mechanism to QUERY which installed packages are affected by known GLSA's would also be tremendously helpful. Like glsa-check? We currently use that, but it really just says which GLSAs are applicable to the system, it doesn't tell me net-misc/asterisk-16.0.1:16 - we've got ways of working from the glsa-check output to that. Of particular annoyance if a GLSA lists multiple packages, of which you have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I can quite quickly determine that emerge -1av net-misc/asterisk:16 will resolve the problem with the lowest possible risk of breakage to other components on the system, and without having to perform a full update. 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. We could import CVE descriptions, but then we'd end up with a huge wall of mostly useless text, such as CVE-2021-35648's: Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS). Supported versions that are affected are 8.0.26 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). MySQL bugs usually have dozens of CVEs associated with them. Would it really be
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon 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. That would greatly increase the care necessary for us to release a GLSA. It's already a big pain (even with the new GLSAMaker being a huge improvement over the old one), and I'd like to make it less of a pain. Maybe a proxy for this information for you would be the "type" field of the impact? > 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 > which then also indicates the "fixed" versions, as has been pointed out > "affected" and "not affected" are inverses. The "atom" attribute of each constraint is using atom syntax, so along with that we get the ability to specify USE exactly like "asterisk-16.X.Y:16[http]". > A mechanism to QUERY which installed packages are affected by known > GLSA's would also be tremendously helpful. Like glsa-check? > > > > 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. We could import CVE descriptions, but then we'd end up with a huge wall of mostly useless text, such as CVE-2021-35648's: Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS). Supported versions that are affected are 8.0.26 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). MySQL bugs usually have dozens of CVEs associated with them. Would it really be useful to have dozens of those paragraphs in GLSAs? Would it be useful to have that text included in a GLSA for MariaDB or PostgreSQL if they're affected by the same issue? On the other end of the spectrum (CVE-2022-41035): Microsoft Edge (Chromium-based) Spoofing Vulnerability. Does that tell anyone anything about the vulnerability? Not really, I think. It'd just be added noise in a GLSA. > 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). It is possible, but is it really useful? CVSS scores are really just arbitrary numbers produced by CNAs (just like descriptions are arbitrary text). Even worse, sometimes the CNA changes the CVSS score, so if we reproduce it into GLSAs, would we have to keep track of any changes and update the GLSA accordingly? The CVE IDs are already exposed by the GLSA as references.uri
Re: [gentoo-dev] [RFC] A new GLSA schema
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
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.
Re: [gentoo-dev] [RFC] A new GLSA schema
> On 10 Nov 2022, at 08:43, Jaco Kroon 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 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
Re: [gentoo-dev] [RFC] A new GLSA schema
Hi, On 2022/11/10 11:40, Matthew Smith wrote: Hi, On 10/11/2022 08:43, Jaco Kroon wrote: A mechanism to QUERY which installed packages are affected by known GLSA's would also be tremendously helpful. You can use glsa-check for this, which comes with portage: https://wiki.gentoo.org/wiki/Portage#glsa-check Very useful for human-readable, not so much for integration into other systems :). We currently parse a lot of that using things like awk etc ... but thinking about it now, one could probably dig into the xml stuff directly, so use glsa-check -l to get the list, then find the xml files and query those using tools more suited for that. Thank you :). Kind Regards, Jaco
Re: [gentoo-dev] [RFC] A new GLSA schema
Hi, On 10/11/2022 08:43, Jaco Kroon wrote: A mechanism to QUERY which installed packages are affected by known GLSA's would also be tremendously helpful. You can use glsa-check for this, which comes with portage: https://wiki.gentoo.org/wiki/Portage#glsa-check Thanks, Matthew
Re: [gentoo-dev] [RFC] A new GLSA schema
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 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
Re: [gentoo-dev] [RFC] A new GLSA schema
* John Helmert III schrieb am 10.11.22 um 14:19 Uhr: > On Thu, Nov 10, 2022 at 02:10:09PM +1000, Marc Schiffbauer wrote: > > * Sam James schrieb am 10.11.22 um 13:58 Uhr: > > > > > > I think we'd rename impact -> description but description would now > > > be "description of the problem" and not "description of the package". > > > > > > +1, but additionally having the short description of the package sounds > > still useful to me, as not always everybody knows what any package is > > exactly for and the description will help a lot in telling the > > impact/danger of your own infra that might be caused by that package. > > > > -Marc > > Are you saying you rely on the background field, which is generally > just the package's DESCRIPTION? Maybe glsa-check should just spit out > the package's DESCRIPTION then too. Sometimes the GLSA-Mails will be send to some team mailbox for example, and a teammember has to decide how urgent an update may be. Having a little description for the software mentioned in the GLSA is helpful then. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 02:10:09PM +1000, Marc Schiffbauer wrote: > * Sam James schrieb am 10.11.22 um 13:58 Uhr: > > > > I think we'd rename impact -> description but description would now > > be "description of the problem" and not "description of the package". > > > +1, but additionally having the short description of the package sounds > still useful to me, as not always everybody knows what any package is > exactly for and the description will help a lot in telling the > impact/danger of your own infra that might be caused by that package. > > -Marc Are you saying you rely on the background field, which is generally just the package's DESCRIPTION? Maybe glsa-check should just spit out the package's DESCRIPTION then too. signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
On Thu, Nov 10, 2022 at 04:43:01AM +0100, Michał Górny wrote: > On Wed, 2022-11-09 at 20:27 -0600, John Helmert III wrote: > > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > > October 2003. It used roughly the same format of the GLSAs we release > > today, in 2022, making that format almost as old as me. > > > > Somewhere along the way, it started to become necessary to target > > multiple version ranges within the same package. The GLSA format > > isn't capable of expressing this. Thus, I propose a new format (an > > example of which I've attached inline below), with the following > > changes from the old format: > > > > - Rework affected to use XML-ified logical operators to specify the > > affected versions, and *don't* use different fields to specify > > vulnerable and unaffected versions. Instead, only list vulnerable > > versions, unaffected versions are implicit. > > Does that imply op="" will now be limited to the standard ebuild > operators? Perhaps it'd be cleaner to take a step further and remove > the attribute in favor of going 100% ebuild syntax (yeah, escaping is > gonna suck there). The added complexity of escaping is exactly what I wanted to avoid! These are already enumerated in the old glsa.dtd [1] for usage in a similar way: https://gitweb.gentoo.org/data/dtd.git/tree/glsa.dtd#n126 > > > > - 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... 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. > BTW have you considered switching to JSON or TOML? ;-) Definitely! But that adds significantly more complexity to implementing this, and given I'm likely to be the only one working on it, I decided against trying it. If I were inventing GLSAs for the first time I'd definitely avoid XML, of course. > > -- > Best regards, > Michał Górny > > signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
* Sam James schrieb am 10.11.22 um 13:58 Uhr: > > I think we'd rename impact -> description but description would now > be "description of the problem" and not "description of the package". +1, but additionally having the short description of the package sounds still useful to me, as not always everybody knows what any package is exactly for and the description will help a lot in telling the impact/danger of your own infra that might be caused by that package. -Marc signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] A new GLSA schema
> On 10 Nov 2022, at 03:43, Michał Górny wrote: > > On Wed, 2022-11-09 at 20:27 -0600, John Helmert III wrote: >> The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of >> October 2003. It used roughly the same format of the GLSAs we release >> today, in 2022, making that format almost as old as me. >> >> Somewhere along the way, it started to become necessary to target >> multiple version ranges within the same package. The GLSA format >> isn't capable of expressing this. Thus, I propose a new format (an >> example of which I've attached inline below), with the following >> changes from the old format: >> >> - Rework affected to use XML-ified logical operators to specify the >>affected versions, and *don't* use different fields to specify >>vulnerable and unaffected versions. Instead, only list vulnerable >>versions, unaffected versions are implicit. > > Does that imply op="" will now be limited to the standard ebuild > operators? Perhaps it'd be cleaner to take a step further and remove > the attribute in favor of going 100% ebuild syntax (yeah, escaping is > gonna suck there). > >> >> - 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. > I think we'd rename impact -> description but description would now be "description of the problem" and not "description of the package". signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] A new GLSA schema
On Wed, 2022-11-09 at 20:27 -0600, John Helmert III wrote: > The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of > October 2003. It used roughly the same format of the GLSAs we release > today, in 2022, making that format almost as old as me. > > Somewhere along the way, it started to become necessary to target > multiple version ranges within the same package. The GLSA format > isn't capable of expressing this. Thus, I propose a new format (an > example of which I've attached inline below), with the following > changes from the old format: > > - Rework affected to use XML-ified logical operators to specify the > affected versions, and *don't* use different fields to specify > vulnerable and unaffected versions. Instead, only list vulnerable > versions, unaffected versions are implicit. Does that imply op="" will now be limited to the standard ebuild operators? Perhaps it'd be cleaner to take a step further and remove the attribute in favor of going 100% ebuild syntax (yeah, escaping is gonna suck there). > > - 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. BTW have you considered switching to JSON or TOML? ;-) -- Best regards, Michał Górny
[gentoo-dev] [RFC] A new GLSA schema
The first GLSA in glsa.git is GLSA-200310-03, the third GLSA of October 2003. It used roughly the same format of the GLSAs we release today, in 2022, making that format almost as old as me. Somewhere along the way, it started to become necessary to target multiple version ranges within the same package. The GLSA format isn't capable of expressing this. Thus, I propose a new format (an example of which I've attached inline below), with the following changes from the old format: - Rework affected to use XML-ified logical operators to specify the affected versions, and *don't* use different fields to specify vulnerable and unaffected versions. Instead, only list vulnerable versions, unaffected versions are implicit. - Drop synopsis and description fields. These fields contain the same information and will be superceded by the existing impact field. - Drop background field. This is usually just the package's description, or some similar text. No reason to reproduce it in GLSAs. What does everyone think? https://www.gentoo.org/dtd/glsa-2.dtd;> Nvidia Drivers: Multiple Vulnerabilities 2022-13-00 2022-13-00 764512 784596 803389 832867 845063 866527 These vulnerabilities could allow a local user with low privileges to gain root privileges. There is no known workaround at this time. All Nvidia drivers 390 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-390.154" All Nvidia drivers 470 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-470.141.03" All Nvidia drivers 510 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-510.85.02" All Nvidia drivers 515.65.01 users should upgrade to the latest version: # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-515.65.01" https://nvd.nist.gov/vuln/detail/CVE-2021-1052;>CVE-2021-1052 https://nvd.nist.gov/vuln/detail/CVE-2021-1053;>CVE-2021-1053 https://nvd.nist.gov/vuln/detail/CVE-2021-1056;>CVE-2021-1056 https://nvd.nist.gov/vuln/detail/CVE‑2021‑1076;>CVE‑2021‑1076 https://nvd.nist.gov/vuln/detail/CVE‑2021‑1077;>CVE‑2021‑1077 https://nvd.nist.gov/vuln/detail/CVE-2021-1090;>CVE-2021-1090 https://nvd.nist.gov/vuln/detail/CVE-2021-1093;>CVE-2021-1093 https://nvd.nist.gov/vuln/detail/CVE-2021-1094;>CVE-2021-1094 https://nvd.nist.gov/vuln/detail/CVE-2021-1095;>CVE-2021-1095 https://nvd.nist.gov/vuln/detail/CVE‑2022‑21813;>CVE‑2022‑21813 https://nvd.nist.gov/vuln/detail/CVE‑2022‑21814;>CVE‑2022‑21814 https://nvd.nist.gov/vuln/detail/CVE-2022-28181;>CVE-2022-28181 https://nvd.nist.gov/vuln/detail/CVE-2022-28183;>CVE-2022-28183 https://nvd.nist.gov/vuln/detail/CVE-2022-28184;>CVE-2022-28184 https://nvd.nist.gov/vuln/detail/CVE-2022-28185;>CVE-2022-28185 https://nvd.nist.gov/vuln/detail/CVE-2022-31607;>CVE-2022-31607 https://nvd.nist.gov/vuln/detail/CVE-2022-31608;>CVE-2022-31608 https://nvd.nist.gov/vuln/detail/CVE-2022-31615;>CVE-2022-31615 larry notlarry larry signature.asc Description: PGP signature
