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.
On 10 Nov 2022, at 03:43, Michał Górny <[email protected]> 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.
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
* 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
I think we'd rename impact -> description but description would now
be "description of the problem" and not "description of the package".
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.
Actually yes! Also a way to check whether my specific configuration is vulnerable for this specific CVE, something like "If you're settingYou're right, but with 19 CVEs (for example), is anyone really- 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.
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.
A mechanism to QUERY which installed packages are affected by known
GLSA's would also be tremendously helpful.
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.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
foo).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=-
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.
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.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. PleaseOf 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,
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.
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+?
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.
On 10 Nov 2022, at 08:43, Jaco Kroon <[email protected]> wrote:we could rely a bit more on package maintainers (myself included) to provide these.
Hi,
On 2022/11/10 06:13, John Helmert III wrote:
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". ObviouslyYou're right, but with 19 CVEs (for example), is anyone really- 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.
interested in hearing about the problem that caused each of the 19
issues? In the current format we've resorted to writing descriptions
like...
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, usechan_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 canthe 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.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.
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,
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).
Hi,
On 2022/11/10 06:13, John Helmert III wrote:
Actually yes!� Also a way to check whether my specific configuration is vulnerable for this specific CVE, something like "If you're settingYou're right, but with 19 CVEs (for example), is anyone really�- 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.
interested in hearing about the problem that caused each of the 19
issues? In the current format we've resorted to writing descriptions like...
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
On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon wrote:
Hi,That would greatly increase the care necessary for us to release a
On 2022/11/10 06:13, John Helmert III wrote:
Actually yes! Also a way to check whether my specific configuration isYou're right, but with 19 CVEs (for example), is anyone really- 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.
interested in hearing about the problem that caused each of the 19
issues? In the current format we've resorted to writing descriptions
like...
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.
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?
We currently use that, but it really just says which GLSAs areI don't think I've seen a single "workaround" and usually the text hereThe "atom" attribute of each constraint is using atom syntax, so along
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.
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 knownLike glsa-check?
GLSA's would also be tremendously helpful.
We could import CVE descriptions, but then we'd end up with a hugeMultiple vulnerabilities have been discovered in $PACKAGE. PleaseOf course giving the full details in the GLSA is a pain in the backside,
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.
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.
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.
Not quite arbitrary, there is supposed to be a set of input variablesIt would also help a great deal to automate that if the CVE scores andIt is possible, but is it really useful? CVSS scores are really
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).
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
fields. From those, it'd be trivial to automate the retrieval of the
CVE data from their authoritative sources (e.g. NIST's NVD API [1] or cvelist.git itself [2]). But, maybe it would be useful to have a
"type" attribute in the uri field indicating what kind of identifier
it is (whether CVE, WSA, XSA, etc), and then other tools could more
easily grok each kind of reference.
[1] https://nvd.nist.gov/developers/vulnerabilities
[2] https://github.com/CVEProject/cvelist
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.
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.
�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.
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
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.
On 11 Nov 2022, at 22:40, Sam James <[email protected]> wrote:
On 11 Nov 2022, at 22:06, Gordon Pettey <[email protected]> wrote:
On Thu, Nov 10, 2022 at 6:27 PM John Helmert III <[email protected]> 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.
On 12 Nov 2022, at 00:04, Gordon Pettey <[email protected]> wrote:of CSAF.
On Fri, Nov 11, 2022 at 4:43 PM Sam James <[email protected]> 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
[2] https://oasis-open.github.io/csaf-documentation/
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?
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?
On Thu, Nov 10, 2022 at 6:27 PM John Helmert III <[email protected]> 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?
CSAF is exactly what we want with GLSA.Thanks, I'll look into it more. Can you offer to help implement it in Portage?
There are already many tools to parse and pretty print the CSAF documents.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:33:18 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,955 |
![https://imgs.xkcd.com/comics/standards.png"](https://imgs.xkcd.com/comics/standards.png"){kind=link}
