Skip to content

Investigate better approach to unknown distro #3193

@willmurphyscode

Description

@willmurphyscode

When releasing a couple of recent new providers, saw a lot of extra coordination due to putting a string literal in a dictionary in Grype was necessary, but otherwise the provider addition was essentially a pure data change.

See for example https://github.com/anchore/grype/pull/3086/changes

This PR was a correct change under the current process, but we shouldn't have needed it. The changes:

  1. Add an enum "secureos" value, but this matches the ID in /etc/os-release. We probably only need special handling when the data sources, the common name, and the release ID don't all agree, but in this case they do.
  2. The {Alias: "secureos", Rolling: true}, change, which tells grype-db to mark secureos as a rolling distro (that is, to ignore distro versions when considering vulnerabilities and fixes). But this change only matters at database build time, so in theory we could just add this value when we build a new database.
  3. Some unit tests to prove that we pick up the enum value.

Based on local testing, changing

return ""

to simply return Type(release.ID) results in correct matching behavior in this case, which suggests its a decent fallback.

The goal of this issue is to change grype so that adding a sort of vanilla distro (meaning we already know how to compare versions for its package manager, /etc/os-release already identifies it reasonably, etc.) should not require a grype release, but just a new database.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

Status

No status

Relationships

None yet

Development

No branches or pull requests

Issue actions