-
Notifications
You must be signed in to change notification settings - Fork 744
Description
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:
- 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. - 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. - Some unit tests to prove that we pick up the enum value.
Based on local testing, changing
Line 147 in 73e8f31
| 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
Assignees
Labels
Type
Projects
Status