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

Prevent advisory creation for packages that don't exist in the repo #387

Closed
luhring opened this issue Oct 24, 2023 · 1 comment
Closed
Labels
enhancement New feature or request

Comments

@luhring
Copy link
Member

luhring commented Oct 24, 2023

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:

  1. The package name is misspelled (including mistakes in the version stream suffix)
  2. 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.
  3. 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:

  1. 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.)
  2. 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:

  1. A ∪ B
  2. A ∩ B
  3. etc.
@luhring
Copy link
Member Author

luhring commented Nov 17, 2023

Implemented this check in wolfi-dev/wolfictl#494, which was incorporated into the advisories repo in #534.

To address the concerns in the description:

  1. 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.

  1. 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.

@luhring luhring closed this as completed Nov 17, 2023
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
None yet
Development

No branches or pull requests

2 participants