Including binary packages in Rocky Linux's OSV records

[Andrew Pollock]

Hi Mustafa,

I was wondering what your thoughts were on being able to include an affected[].package for each binary package produced by a vulnerable source package?

Isabella is trying to use Rocky Linux OSV records to inform some container image scanning, but finding the lack of binary package information makes this challenging to get the desired level of accuracy.

A concrete example: RLSA-2023:0096 refers to dbus, and the dbus source package produces d-bus, dbus-common, etc.

regards

Andrew

--

Andrew Pollock Software 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.

[Mustafa Gezen]

Hi Andrew,

We can definitely do that. I can't recall exactly but that might've been the behavior at first but it was changed to match other distributions.

Should we add the packages to affected[] or in the vendor specific section somewhere?

Mustafa

[Oliver Chang]

I think the reason that we didn't go with affected[] was because of the OSV-Schema definition (The "Rocky Linux" ecosystem refers explicitly to source packages) and consistency with other Linux distros. We'd have to refine the schema definitions to support this, or we go with `ecosystem_specific` as Mustafa suggested. 

As an alternative, how easy generally would it be for Rocky Linux users to map their binary packages to source packages when scanning for vulnerabilities? Is this metadata readily available via either an API, or through local package metadata? 

--

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/CAOGTp1TYZNgnq_BfJN5ThHzpjr4mGUpm5bJ2rYX-WELaYb2ECQ%40mail.gmail.com.

[Oliver Chang]

On Fri, 15 Sept 2023 at 09:54, Oliver Chang <och...@google.com> wrote:

I think the reason that we didn't go with affected[] was because of the OSV-Schema definition (The "Rocky Linux" ecosystem refers explicitly to source packages) and consistency with other Linux distros. We'd have to refine the schema definitions to support this, or we go with `ecosystem_specific` as Mustafa suggested. 

(I've filed https://github.com/ossf/osv-schema/issues/202 to start some discussions). 

[Mustafa Gezen]

Andrew,

I'm assuming someone on your team needs more information from the advisories. As an interim solution I recommend they look into the Errata API.

Taking the ID from the OSV advisory and adding it to https://apollo.build.resf.org/api/v3/advisories/{ID} should get them enough information.

That endpoint will also include information about source and descendant packages in modules.

Might be faster to iterate through the Errata API advisory listing rather than doing OSV -> Advisory.

https://apollo.build.resf.org/api/v3/advisories/

The listing performance is still being worked on, but it should be good enough for now. https://apollo.build.resf.org/api/v3/advisories?size=100 should allow you to process all advisories in about 55 pages as of now.

Otherwise, I'll be following that issue (thanks for creating that Oliver) and will be adding the agreed upon solution to our OSV API.

Mustafa

[Oliver Chang]

Hi Mustafa,

Hope you've been well.

Following up on this thread once more since we've had some requests from our users to include binary package info in the OSV records. 

Sadly we don't have consensus yet on a formal schema definition, but in the meantime would it be possible to add this information into  `database_specific` into the existing OSV entries?  

i.e. something like:

```

           "database_specific": {

            "yum_repository": "AppStream"

            "binary_packages": [

               "...",

             ],
          }

```

Kind regards,

--

Oliver

[Isabella Adu]

Hi all,

A week ago, a customer raised a ticket that the fixed version for python3-pyyaml was reported as 3.12-16.module+el8.5.0+706+735ec4b3, though this version of python3-pyyaml does not exist. Since the rocky osv feed does not contain binary package vulnerabilities, a workaround we decided on was to mark the binary package as vulnerable if its source package is vulnerable at that version. This also means that the fixed version we report is the source package's fixed version. The source package pyyaml, goes all the way to the listed fixed version at  3.12-16.module+el8.5.0+706+735ec4b3, but the binary package python3-pyyaml only goes up to python3-pyyaml-3.12-12.el8.x86_64. The RLSA is osv-vulnerabilities/Rocky Linux/RLSA-2019:3335.json.

I am proposing adding a new entry to the affected list per binary package. pls let me know what you think.

Best,

Isabella.

[Oliver Chang]

Hi Mustafa,

Thanks again for helping us with the bucket freshness issue.

Apologies for the ping, but would you also be able to help us with encoding the list of binary packages in the exported OSV advisories using `database_specific`? 

This would be extremely helpful for our downstream users.

Kind regards,

Oliver

[Mustafa Gezen]

Hi folks,

I've been shifting focus and don't do a lot of work on the errata system anymore but I'll let the team know and see if anyone can pick this up.

Sorry for the delay on this.

Mustafa