Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional globs for Debian cataloger #2692

Open
njv299 opened this issue Mar 5, 2024 · 2 comments
Open

Additional globs for Debian cataloger #2692

njv299 opened this issue Mar 5, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@njv299
Copy link

njv299 commented Mar 5, 2024

What would you like to be added:

I have observed status files in real-world filesystems at paths that vary slightly from the set of globs currently searched for by the Debian DB cataloger. The current set of globs is:

"**/var/lib/dpkg/status", "**/var/lib/dpkg/status.d/*", "**/lib/opkg/info/*.control", "**/lib/opkg/status"

In the wild, I've seen usr/lib/dpkg/status (this is currently handled for opkg, but not dpkg). It seems like this would be as simple as chaning the current glob of **/var/lib/dpkg/status to be **/lib/dpkg/status.

In addition, I've observed filesystems built using the Itsy Package Management System (aka 'ipkg') that appear to have the exact same status file format used by Debian (dpkg) and OpenWRT (opkg). I believe that simply adding a glob of **/lib/ipkg/status would handle these filesystems as well. PURL generation for these might need to be re-evaluated, though, as the deb/debian type and namespace would likely not be correct. As far as I can tell from the current PURL spec there is no current specification for ipkg PURLs. I nominate that PURLs for such packages should be in the form of pkg:ipkg/<name>@<version> until official specifications are created.

Why is this needed:

Certain varieties of Debian, OpenWRT, and Ipkg-based filesystems are not being scanned fully by Syft.

@njv299 njv299 added the enhancement New feature or request label Mar 5, 2024
@tgerla
Copy link
Contributor

tgerla commented Mar 7, 2024

Hey @njv299, thanks for the report. For the first part, I think changing the glob as you suggest would be fine. Do you want to submit a pull request with the change? Or we can put this in our backlog and we will get to it at some point.

For the second part, we are thinking that we should implement ipkg and opkg as separate catalogers for a number of reasons. We're going to open a separate feature request and link to this issue and we can discuss there.

Thanks!

@kzantow
Copy link
Contributor

kzantow commented Mar 7, 2024

A quick note about the PURL, it looks like the namespace is what we'd want to set for opkg and ipkg types; since there were a few different requests rolled into the description, this can cover expanding the dpkg globs in use.

I added another issue to track the ipkg support; see:

And there was an existing issue to track opkg support:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

3 participants