Have you considered publishing Rocky Linux security errata in OSV format?

[Andrew Pollock]

Hello from GOSST's OSV team!

Adding Rocky Linux to our supported Linux distributions is a topic that recently came up in conversation, and we were wondering if you've given any consideration to publishing your security errata in the OSV format? This would greatly simplify our ability to include your vulnerabilities in our database.

Please feel free to get in touch if you have any questions or would like to explore this further. We've also got a Slack if you'd prefer.

regards

Andrew

--

Andrew Pollock Security Engineer, Google Open Source Security Team | apol...@google.com Google LLC

This email is confidential. If you are not the right addressee, please inform the sender and please erase this email including any attachments.

[Gregory Kurtzer]

Hi Andrew, (et. al.,)

That is a very interesting idea. Mustafa (CC'ed) is doing some work to our Errata system right now for v9 so this is a good time to ask about this. 

Mustafa, thoughts?

Thanks!

[Mustafa Gezen]

Hi Andrew,

The OSV format seems to be very close to the format we currently have. I don't see a reason why we can't support it.

I'll look into that further.

Thanks,

Mustafa

[Andrew Pollock]

Hi Mustafa,

That's fantastic news. Please feel free to get in touch if you have any questions.

regards

Andrew

Andrew Pollock Security Engineer, Google Open Source Security Team | +61419788191 | apol...@google.com Google LLC

[Oliver Chang]

Thanks for the reply Mustafa! 

We'd really like to support Rocky Linux in https://github.com/google/osv-scanner, and the first step here would be to have Rocky Linux advisories in the OSV format :) 

+1 to Andrew's comment -- Please don't hesitate to reach out if you have any questions or want to discuss any of this. We also have a Slack channel on the OpenSSF Slack at #osv_schema channel

Cheers, 

--

Oliver

--
You received this message because you are subscribed to the Google Groups "osv-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-discuss/CAAJmWJ%2B0p64mTi9Rvz%3DhdZ-itieK57eOapm10%2BgaiPQTeWWsDA%40mail.gmail.com.

[Mustafa Gezen]

Hi Oliver,

We've now started serving the OSV format as well.

You can find it at this endpoint: https://apollo.build.resf.org/api/v3/osv/ or https://apollo.build.resf.org/api/v3/osv/{ID}

Swagger UI here: https://apollo.build.resf.org/docs

I wasn't able to find much about pagination, so if we need to make any changes to the approach, please let me know.

I was also not sure if we were supposed to list one affected entry per source rpm, or per installable package.

Currently the affected list follows the per installable package approach.

Appreciate any feedback.

Thanks,

Mustafa

[Oliver Chang]

Hi Mustafa,

Thank you very much for this update and the amazing turnaround. This is awesome! 

Some comments:

- There are a bunch of null fields (e.g. `"fixed": null`, `"database_specific": {}`). Would it be possible to just exclude these from being included automatically? It would help make the output a lot more cleaner, and make it compliant with the spec (We have a JSON schema here: https://github.com/ossf/osv-schema/blob/main/validation/schema.json)

- "repo" under "ranges" should be a GIT repository URL. Currently this seems to be used for encoding a Rocky Linux-specific field, which is not correct: 

       "ranges": [

        {
          "type": "ECOSYSTEM",
          "repo": "AppStream",
          "events": [

- There are two CVSS scores in at least https://apollo.build.resf.org/api/v3/osv/RLSA-2023:0208: 

  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
    },
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N"
    }
  ],

The actual score looks very slightly different. Technically this is not allowed by the spec, and there should only be a single CVSS_V3 score. If there are multiple, they can be encoded at a per-affected package level (https://github.com/ossf/osv-schema/pull/106 which will be part of the upcoming 1.4.0 schema release). 

- The ecosystem needs to be defined in the OSV-Schema here. Please feel free to open a PR here to add a definition for Rocky Linux! 

> I was also not sure if we were supposed to list one affected entry per source rpm, or per installable package.

What makes the most sense for Rocky Linux here? For Debian and Alpine, the affected entries refer to source packages, to make things a bit more concise and avoid some complexity with expanding the binary/installable packages. 

Thank you very much once again. 

Cheers,

--

Oliver

[Mustafa Gezen]

Hi Oliver,

1. Of course, we can remove redundant fields.

2. We can remove the repo value, it's an indication on which RPM repository it is located in but it is not something that is usually required to publish, I can move that to database specific eventually right?

3. I think I misunderstood that field, sorry. I included the scoring vector for each CVE, but we can remove that too. The Debian one doesn't seem to include severity

4. I'll send a PR as soon as possible

Thank you so much for the amazing feedback! I also realized that we return non-security reports as well, we will correct that for the next update.

Mustafa

[Andrew Pollock]

Hi Mustafa,

Yes, the database specific field can hold information like the RPM repository.

Regarding the CVSS_V3 severity scores in your records, this is entirely supported by the schema, I think Oliver was saying that having two of the same "type" (CVSS_V3 in this case) was not.

It's certainly very cool that you're providing richer OSV records that have this information in them, I'd encourage you to continue having them in there, just per the spec.

regards

Andrew

[Oliver Chang]

Following up on this thread once more :) Do you have any timelines on the next update? We'd also like to give a very short call out to Rocky Linux's OSV support in a blog post that we've been planning on the OSV schema. 

Once again, thank you very much for working on this. 

Best,

--

Oliver

[Mustafa Gezen]

Hi Oliver,

We should be able to finalize the OSV API this week. Really exciting that you folks want to mention Rocky!

I'll let you know when the final changes have been deployed!

Thank you so much for your valuable feedback.

Mustafa

[Mustafa Gezen]

Hi Andrew,

Thank you for the clarification, we're working on properly conforming to the spec and will keep the CVSS_V3 scores in the advisories.

Mustafa

[Oliver Chang]

Thanks Mustafa! 

In the interests of linking out from our blog post in our shoutout, which link should we use? Would https://apollo.build.resf.org/docs#/osv be the best one? 

Thanks,

--

Oliver

[Mustafa Gezen]

Hi,

https://distro-tools.rocky.page/apollo/openapi/#osv would work better

Mustafa

[Mustafa Gezen]

Hi all,

I've sent a PR to add the `rocky-linux` ecosystem as well as recognize `RLSA` and `RXSA` advisories. (We're using RXSA for SIGs, which the GCP kernels use for example).

https://github.com/ossf/osv-schema/pull/118

For src.rpms that appear in multiple repositories at the same time (like kernel-rt is published in RT and NFV) there is one affected entry for each.

If desired, I can collapse those entries into one

I've moved the repository name to `database_specific` like this:

          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "fixed": "5.14.0-162.18.1.rt21.181.el9_1"
                }
              ],
              "database_specific": {
                "yum_repository": "NFV"
              }
            }
          ]

[Andrew Pollock]

Hi,

With https://github.com/ossf/osv-schema/pull/118 merged, I was wondering when we can start having OSV.dev import from Rocky Linux?

regards

Andrew

[Mustafa Gezen]

Hi Andrew,

Totally forgot to get back to you. Sorry!

Everything should be ready to go on the Rocky API side.

List: https://apollo.build.resf.org/api/v3/osv

Get: https://apollo.build.resf.org/api/v3/ID

Mustafa

[Andrew Pollock]

Hi Mustafa,

I wanted to get back to you with an update on where things are at on our end...

It's really cool that Rocky Linux is serving up their OSV records via a REST API. It's inspired us to support ingesting from a REST API as an additional option (see https://github.com/google/osv.dev/issues/1235)

The challenge on our end is that we're fully booked on other work foreseeably until 2023'Q4 at this stage, so we can't commit to having the bandwidth to implement support for this until then at the earliest.

That leaves us with a few options, and these aren't exhaustive:

• Rocky Linux serves the same data by one of currently supported ingestion mechanisms (i.e. a Git repository or a public GCS bucket)
• Rocky Linux contributes a REST API ingestion implementation
• We wait until 2023'Q4 when we have bandwidth to implement a REST API ingestion method

Please let us know what your thoughts are, and we can go from there.

regards

Andrew

[Mustafa Gezen]

Hi Andrew,

Thanks for the update!

We've created a GCS bucket https://storage.googleapis.com/resf-osv-data that we will export the data to.

Initially we'll do nightly updates and pull from our API and export it to the bucket, if necessary we can make it more frequent.

I can also see if we can take the time to eventually contribute a REST API ingestion method, but can't promise anything on that.

Currently we just do a list from the API and then export individual advisories as json files to the bucket. If another format would be easier to work with, let me know.

Mustafa

[Andrew Pollock]

Hi, thanks for the quick response, responses in line.

On Fri, 21 Apr 2023 at 03:36, Mustafa Gezen <mus...@rockylinux.org> wrote:

Hi Andrew,

Thanks for the update!

We've created a GCS bucket https://storage.googleapis.com/resf-osv-data that we will export the data to.

Initially we'll do nightly updates and pull from our API and export it to the bucket, if necessary we can make it more frequent.

Nice, this works for us, I'll proceed with adding this to our staging instance in the next week or two for some shake-down testing, and if that pans out, add it to our production instance.

 

I can also see if we can take the time to eventually contribute a REST API ingestion method, but can't promise anything on that.

Don't sweat it, if you get to it before we do, great, if not we'll get to it eventually. The pressure is off in the short term if we've got the data available to ingest from a supported medium.

 

Currently we just do a list from the API and then export individual advisories as json files to the bucket. If another format would be easier to work with, let me know.

From a quick inspection of the bucket, I think this looks fine and as expected.

[Andrew Pollock]

Hi,

Just to update you on where we're at, we've just added this bucket source to our staging instance to test out importing, and I'll check it towards the end of the week, and if everything appears to be in order, we'll add it to our production database importer next week.

regards

Andrew

[Mustafa Gezen]

Awesome, thank you for the update!

[Andrew Pollock]

Hello again,

We didn't see any barriers to moving forward with integrating Rocky Linux this week, so I'm very pleased to advise that Rocky Linux is now available in our production database: https://osv.dev/list?ecosystem=Rocky+Linux

Thank you for this collaboration and contribution!

We will have an upcoming blog post about this at http://osv.dev/blog, if you'd like to review the PR prior to publication, please let me know your GitHub username.

regards

Andrew

[Mustafa Gezen]

Yay, thank you so much for helping us through the process Andrew and Oliver. If there are any other issues, feel free to reach out

[Michael Kedar]

Hi,

We've recently updated the OSV Schema to refine and clarify the usage of the 'aliases' and 'related' fields.

Currently, Rocky Linux seems to be using the 'aliases' field to list the multiple distinct CVEs a patch addresses. In our revised schema definition, these should come under the 'related' field instead. Could you please update your OSV records to use the 'related' field for these instead?
If you have any questions, I'd be happy to discuss further.

Thanks,
Michael

[Oliver Chang]

Hi Mustafa!

Thanks again for helping get OSV support working for Rocky Linux. 

We just have some follow up requests and questions based on some feedback we're seeing from consumers of the OSV feed.

- We've recently updated the OSV Schema to refine and clarify the usage of the 'aliases' and 'related' fields (rationale). This means that Rocky's current usage of `aliases` should be changed to `related`. Would you be able to make this change? 

- OSV events don't seem to include an epoch in the version string. E.g. on https://apollo.build.resf.org/api/v3/osv/RLSA-2023:0096, the fixed version is "1.12.8-23.el8_7.1" (while the purl has an `epoch=1`). Would it be more accurate to list this as "1:1.12.8-23.el8_7.1"?

- The purl field seems to include the fixed version (e.g. on https://apollo.build.resf.org/api/v3/osv/RLSA-2023:0096), the purl is listed as "pkg:rpm/rocky-linux/db...@1.12.8-23.el8_7.1?distro=rocky-linux-8&epoch=1". This is intended to encode the base PURL without any version information (`events` is used for version matching). Would it be possible to use "pkg:rpm/rocky-linux/dbus?distro=rocky-linux-8" as the PURL instead?  

Thanks again,

--

Oliver

[Mustafa Gezen]

Hi Oliver,

We can definitely make the necessary changes. I'll take a look and get back to you!

Mustafa

[Mustafa Gezen]

Hi Oliver,

I've deployed the changes that should address all your requests.

Thanks,

Mustafa

[Oliver Chang]

Thank you Mustafa!! 

--

Oliver