[gentoo-dev] [RFC] A new GLSA schema

[gentoo-dev] [RFC] A new GLSA schema

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 5092 bytes --]

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?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glsa SYSTEM "https://www.gentoo.org/dtd/glsa-2.dtd">
<glsa id="202213-00">
  <title>Nvidia Drivers: Multiple Vulnerabilities</title>
  <announced>2022-13-00</announced>
  <revised count="1">2022-13-00</revised>
  <bug>764512</bug>
  <bug>784596</bug>
  <bug>803389</bug>
  <bug>832867</bug>
  <bug>845063</bug>
  <bug>866527</bug>
  <affected>
    <any>
      <and>
        <constraint op="ge" atom="x11-drivers/nvidia-drivers-390"/>
        <constraint op="lt" atom="x11-drivers/nvidia-drivers-390.154"/>
      </and>
      <and>
        <constraint op="ge" atom="x11-drivers/nvidia-drivers-470"/>
        <constraint op="lt" atom="x11-drivers/nvidia-drivers-470.141.03"/>
      </and>
      <and>
        <constraint op="ge" atom="x11-drivers/nvidia-drivers-510.85"/>
        <constraint op="lt" atom="x11-drivers/nvidia-drivers-510.85.02"/>
      </and>
      <and>
        <constraint op="ge" atom="x11-drivers/nvidia-drivers-515.65"/>
        <constraint op="lt" atom="x11-drivers/nvidia-drivers-515.65.01"/>
      </and>
    </any>
  </affected>
  <impact type="high">
    <p>These vulnerabilities could allow a local user with low privileges to gain root privileges.</p>
  </impact>
  <workaround>
    <p>There is no known workaround at this time.</p>
  </workaround>
  <resolution>
    <p>All Nvidia drivers 390 users should upgrade to the latest version:</p>

    <code>
      # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-390.154"
    </code>

    <p>All Nvidia drivers 470 users should upgrade to the latest version:</p>

    <code>
      # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-470.141.03"
    </code>

    <p>All Nvidia drivers 510 users should upgrade to the latest version:</p>

    <code>
      # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-510.85.02"
    </code>

    <p>All Nvidia drivers 515.65.01 users should upgrade to the latest version:</p>

    <code>
      # emerge --ask --oneshot --verbose ">=x11-drivers/nvidia-drivers-515.65.01"
    </code>
  </resolution>
  <references>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2021-1052">CVE-2021-1052</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2021-1053">CVE-2021-1053</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2021-1056">CVE-2021-1056</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE‑2021‑1076">CVE‑2021‑1076</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE‑2021‑1077">CVE‑2021‑1077</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2021-1090">CVE-2021-1090</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2021-1093">CVE-2021-1093</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2021-1094">CVE-2021-1094</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2021-1095">CVE-2021-1095</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE‑2022‑21813">CVE‑2022‑21813</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE‑2022‑21814">CVE‑2022‑21814</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2022-28181">CVE-2022-28181</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2022-28183">CVE-2022-28183</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2022-28184">CVE-2022-28184</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2022-28185">CVE-2022-28185</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2022-31607">CVE-2022-31607</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2022-31608">CVE-2022-31608</uri>
    <uri link="https://nvd.nist.gov/vuln/detail/CVE-2022-31615">CVE-2022-31615</uri>
  </references>
  <metadata tag="requester" timestamp="2022-09-28T14:25:19.979184Z">larry</metadata>
  <metadata tag="reviewer" timestamp="2022-09-29T14:25:19.979184Z">notlarry</metadata>
  <metadata tag="submitter" timestamp="2022-09-30T14:25:19.985055Z">larry</metadata>
</glsa>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Michał Górny]

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

Re: [gentoo-dev] [RFC] A new GLSA schema

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]



> On 10 Nov 2022, at 03:43, Michał Górny <mgorny@gentoo.org> 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".

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

* 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

* 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.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]

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:

<!ATTLIST vulnerable range      (le|lt|eq|gt|ge|rlt|rle|rgt|rge)      #REQUIRED

[1] 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
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jaco Kroon]

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

Re: [gentoo-dev] [RFC] A new GLSA schema

[Matthew Smith]

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

[Jaco Kroon]

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

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 4024 bytes --]



> On 10 Nov 2022, at 08:43, Jaco Kroon <jaco@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.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jaco Kroon]

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.

Re: [gentoo-dev] [RFC] A new GLSA schema

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 6004 bytes --]

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 
> <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 "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
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

> 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
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jaco Kroon]

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
>> <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 "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 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.

Fair.  Both those descriptions can be significantly better.

>
>> 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?
Not quite arbitrary, there is supposed to be a set of input variables 
that is from what I recall yes/no in nature (eg, directly remotely 
exploitable, require auth to exploit etc ...) that factors into a 
formula that generates the score.  The Chromium one above I note has 
been manually adjusted the severity to moderate in spite of the 
calculated base score being 8.2.
>
> 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.

Yes, so glsa-check -cl already provides the CVE id's, and yes, given the 
API url or git repo this can be automated, but why not have glsa-check 
do that?  Ie, if I do glsa-check -cd 202211-?? then that additional 
information can be retrieved and dumped too. It would be helpful if at 
least some of this information could be automatically pulled in and 
displayed without having to build further tooling:

$ curl https jqservices.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2022-41035

In particular this is useful:

             {
               "source": "secure@microsoft.com",
               "type": "Primary",
               "cvssData": {
                 "version": "3.1",
                 "vectorString": 
"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
                 "attackVector": "NETWORK",
                 "attackComplexity": "HIGH",
                 "privilegesRequired": "NONE",
                 "userInteraction": "REQUIRED",
                 "scope": "CHANGED",
                 "confidentialityImpact": "HIGH",
                 "integrityImpact": "HIGH",
                 "availabilityImpact": "HIGH",
                 "baseScore": 8.3,
                 "baseSeverity": "HIGH"
               },
               "exploitabilityScore": 1.6,
               "impactScore": 6.0
             },

Even this potentially, which really gives somewhat more information than 
the CVE itself (in this case at least):

         "references": [
           {
             "url": 
"https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41035",
             "source": "secure@microsoft.com",
             "tags": [
               "Patch",
               "Vendor Advisory"
             ]
           },
           {
             "url": "https://security.gentoo.org/glsa/202210-16",
             "source": "secure@microsoft.com"
           }
         ]

Obviously the gentoo link doesn't really help, but the former gives good 
details lower down.

So perhaps rather than storing reference links one could store:

<references>
    <cve>CVE-2022-41035</cve>
<url>https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41035</url>
</references>

Retrieving the CVSS details like above can then at a later stage go into 
tooling, for now just converting <cve> into "another URL" for display is 
fine, this doesn't step back, but allows for future changes to utilize 
the API calls to retrieve more details from the CVE itself for display 
as part of the dump (which would then obviously always display the 
latest information).

> [1] https://nvd.nist.gov/developers/vulnerabilities
> [2] https://github.com/CVEProject/cvelist
>
Kind Regards,
Jaco

Re: [gentoo-dev] [RFC] A new GLSA schema

[Mart Raudsepp]

Ü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

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jonas Stein]

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

[John Helmert III]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

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
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

On Thu, Nov 10, 2022 at 6:27 PM John Helmert III <ajak@gentoo.org> 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?

[-- Attachment #2: Type: text/html, Size: 1445 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]



> On 11 Nov 2022, at 22:06, Gordon Pettey <petteyg359@gmail.com> wrote:
> 
> On Thu, Nov 10, 2022 at 6:27 PM John Helmert III <ajak@gentoo.org> 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.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]



> On 11 Nov 2022, at 22:40, Sam James <sam@gentoo.org> wrote:
> 
> 
> 
>> On 11 Nov 2022, at 22:06, Gordon Pettey <petteyg359@gmail.com> wrote:
>> 
>> On Thu, Nov 10, 2022 at 6:27 PM John Helmert III <ajak@gentoo.org> 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?

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jonas Stein]

>>>> [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

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]



> On 12 Nov 2022, at 00:01, Jonas Stein <jstein@gentoo.org> 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?

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Jonas Stein]

>> 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

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Fri, Nov 11, 2022 at 4:43 PM Sam James <sam@gentoo.org> 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.

[-- Attachment #2: Type: text/html, Size: 1009 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]



> On 12 Nov 2022, at 00:04, Gordon Pettey <petteyg359@gmail.com> wrote:
> 
> On Fri, Nov 11, 2022 at 4:43 PM Sam James <sam@gentoo.org> 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.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [RFC] A new GLSA schema

[Michał Górny]

On Fri, 2022-11-11 at 16:06 -0600, Gordon Pettey wrote:
> On Thu, Nov 10, 2022 at 6:27 PM John Helmert III <ajak@gentoo.org> 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