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

The minimum quality bar is sustainably enforced by OSV.dev #2188

Open
andrewpollock opened this issue May 9, 2024 · 2 comments
Open

The minimum quality bar is sustainably enforced by OSV.dev #2188

andrewpollock opened this issue May 9, 2024 · 2 comments
Assignees

Comments

@andrewpollock
Copy link
Contributor

Records below the quality bar are not imported into or exported by OSV.dev

@andrewpollock
Copy link
Contributor Author

#2582 and #2766 are the first parts of this work

andrewpollock added a commit to andrewpollock/osv.dev that referenced this issue Nov 7, 2024
This commit explicitly sets strict mode on a per-repository basis. This
change is a no-op until the importer's `--strict_validation` flag is
also set to True, and it will then be a no-op for all sources other than
the `cve-osv` one where we can trial having it enabled.

Part of google#2188
andrewpollock added a commit that referenced this issue Nov 8, 2024
#2837)

This commit explicitly sets strict mode on a per-repository basis. This
change is a no-op until the importer's `--strict_validation` flag is
also set to True, which will still then be a no-op for all sources other
than `cve-osv` where we can trial having it enabled.

Part of #2188
andrewpollock added a commit to andrewpollock/osv.dev that referenced this issue Nov 8, 2024
This only impacts sources that have `strict_validation` enabled for
them, such as in google#2837

Part of google#2188
andrewpollock added a commit that referenced this issue Nov 13, 2024
This only impacts sources that have `strict_validation` enabled for
them, such as in #2837

Part of #2188
andrewpollock added a commit to andrewpollock/osv.dev that referenced this issue Nov 26, 2024
This replicates staging's explicit per-source setting of strict
validation to false and harmonises a few unnecessary divergences that
have crept in between the two files.

Part of google#2191 and google#2188
andrewpollock added a commit to andrewpollock/osv.dev that referenced this issue Nov 26, 2024
This replicates staging's explicit per-source setting of strict
validation to false and harmonises a few unnecessary divergences that
have crept in between the two files.

Part of google#2191 and google#2188
andrewpollock added a commit that referenced this issue Nov 26, 2024
…on (#2899)

This replicates staging's explicit per-source setting of strict
validation to false and harmonises a few unnecessary divergences that
have crept in between the two files.

Part of #2191 and #2188
andrewpollock added a commit to andrewpollock/osv.dev that referenced this issue Dec 1, 2024
This enables strict mode in the OSV.dev staging environment for all
sources in staging that have been deemed already be publishing 100% OSV
JSON Schema compliant records already, with the notable exception of the
RustSec Advisory Database due to rustsec/advisory-db#2135

Part of google#2188
andrewpollock added a commit that referenced this issue Dec 2, 2024
…#2943)

This enables strict mode in the OSV.dev staging environment for all
sources in staging that have been deemed already be publishing 100% OSV
JSON Schema compliant records, with the notable exception of the RustSec
Advisory Database due to
rustsec/advisory-db#2135 and the inclusion of
PyPA despite pypa/advisory-database#217
(because of pypa/advisory-database#208)

Part of #2188
@andrewpollock
Copy link
Contributor Author

Status Update

Piloting JSON Schema compliance enforcement in Staging for all sources (except RustSec Advisory DB until rustsec/advisory-db#2135 gets addressed)

Next Steps

  • Assess effectiveness and enable for Production
  • Integrate OSV Linter with Importer

andrewpollock added a commit to andrewpollock/osv.dev that referenced this issue Dec 2, 2024
This adds functionality to the worker to clear any existing import
findings for a record that previously failed to import, but now does.
This avoids confusing historical findings existing for records that are
successfully importing now.

Part of google#2189 and google#2188
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

1 participant