Including binary packages in Rocky Linux's OSV records

10 views
Skip to first unread message

Andrew Pollock

unread,
Sep 14, 2023, 7:17:25 PMSep 14
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 PMSep 14
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 PMSep 14
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 PMSep 14
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 PMSep 20
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
Reply all
Reply to author
Forward
0 new messages