Including binary packages in Rocky Linux's OSV records

90 views
Skip to first unread message

Andrew Pollock

unread,
Sep 14, 2023, 7:17:25 PM9/14/23
to Mustafa Gezen, Isabella Adu, osv-discuss
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

unread,
Sep 14, 2023, 7:30:21 PM9/14/23
to Andrew Pollock, Isabella Adu, osv-discuss
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

unread,
Sep 14, 2023, 7:54:31 PM9/14/23
to Mustafa Gezen, Andrew Pollock, Isabella Adu, osv-discuss
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

unread,
Sep 14, 2023, 8:00:52 PM9/14/23
to Mustafa Gezen, Andrew Pollock, Isabella Adu, osv-discuss
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

unread,
Sep 20, 2023, 6:33:10 PM9/20/23
to Oliver Chang, Andrew Pollock, Isabella Adu, osv-discuss
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.

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

unread,
Apr 1, 2024, 10:25:23 PMApr 1
to Mustafa Gezen, Andrew Pollock, Isabella Adu, osv-discuss
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

unread,
Apr 2, 2024, 2:00:48 PMApr 2
to Oliver Chang, Mustafa Gezen, Andrew Pollock, osv-discuss
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

unread,
Apr 20, 2024, 1:15:16 AMApr 20
to Mustafa Gezen, Andrew Pollock, Isabella Adu, osv-discuss
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

unread,
Apr 20, 2024, 1:19:05 AMApr 20
to Oliver Chang, Andrew Pollock, Isabella Adu, osv-discuss
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
Reply all
Reply to author
Forward
0 new messages