You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, there's nothing preventing a contributor from adding new advisories to the repo for packages that don't exist in Wolfi.
These additions are usually a mistake, such as when:
The package name is misspelled (including mistakes in the version stream suffix)
The package used to exist in the distro but has since been removed or moved to another distro, and thus the advisory should instead be created in the correct advisories repo.
The package never existed in this distro but does exist in another distro (e.g. it's an enterprise package).
In other scenarios, it's not a mistake (it's intentional), such as when:
The package is being created for the first time, so corresponding advisories are created immediately to maintain our coverage in the advisory data set. (In these cases, the CVE scan in Wolfi's CI won't pass until there's advisory data that accounts for the package's vulnerabilities.)
The advisory was introduced back when the package did exist in the distro. At the time of writing, we have not decided to remove or adjust advisory documents for this scenario (this is its own discussion with tradeoffs), so they would still exist in the repo when new PRs are opened.
Proposal
Add functionality to the advisories repo's CI to fail whenever an advisory document's .package.name isn't found in Wolfi.
Concerns
This solution doesn't account for the scenarios listed in the "not a mistake" category above. We'll need to figure out how to account for those scenarios.
Technical considerations
We should clarify the definition of when a package "exists in the distro". There are two relevant sets: (A) packages currently defined in the distro repo (e.g. in https://github.com/wolfi-dev/os on main), and (B) found in the APKINDEX for the distro.
Thus, there are several possibilities for how we define "exists in the distro" using these sets, such as:
A ∪ B
A ∩ B
etc.
The text was updated successfully, but these errors were encountered:
Implemented this check in wolfi-dev/wolfictl#494, which was incorporated into the advisories repo in #534.
To address the concerns in the description:
The package is being created for the first time, so corresponding advisories are created immediately to maintain our coverage in the advisory data set. (In these cases, the CVE scan in Wolfi's CI won't pass until there's advisory data that accounts for the package's vulnerabilities.)
We're accepting that Wolfi's CVE scan will fail in this case. For now, it's a non-blocking CI check, so we can merge in spite of the failure. Perhaps in the future we can make this check smarter by incorporating open PRs in the advisories repo.
The advisory was introduced back when the package did exist in the distro. At the time of writing, we have not decided to remove or adjust advisory documents for this scenario (this is its own discussion with tradeoffs), so they would still exist in the repo when new PRs are opened.
At this point, we're updating our stance here to not maintain advisory documents for packages that are no longer defined in the distro. If we ever want to revisit this, we should do so via #277, to ensure all documents still refer to a currently maintained package, meanwhile allowing us to maintain references to defunct packages.
Context
Today, there's nothing preventing a contributor from adding new advisories to the repo for packages that don't exist in Wolfi.
These additions are usually a mistake, such as when:
In other scenarios, it's not a mistake (it's intentional), such as when:
Proposal
Add functionality to the advisories repo's CI to fail whenever an advisory document's
.package.name
isn't found in Wolfi.Concerns
This solution doesn't account for the scenarios listed in the "not a mistake" category above. We'll need to figure out how to account for those scenarios.
Technical considerations
We should clarify the definition of when a package "exists in the distro". There are two relevant sets: (A) packages currently defined in the distro repo (e.g. in https://github.com/wolfi-dev/os on
main
), and (B) found in the APKINDEX for the distro.Thus, there are several possibilities for how we define "exists in the distro" using these sets, such as:
The text was updated successfully, but these errors were encountered: