.github: weekly CVE applicability sync for bundled deps#1914
Draft
jelmerdehen wants to merge 1 commit into
Draft
.github: weekly CVE applicability sync for bundled deps#1914jelmerdehen wants to merge 1 commit into
jelmerdehen wants to merge 1 commit into
Conversation
Adds an automated weekly job that diffs published upstream GHSAs against the in-tree CVE applicability logs for each bundled dep in third-party/versions.mak (pjproject, jansson, libjwt). Opens a PR with placeholder rows for any CVE that has no recorded applicability decision. Same shape as Erlang/OTP's openvex-sync.yml + create-openvex-pr.sh running against their vendored OpenSSL. Behaviour: no missing entries -> no commit, no PR. Missing entries -> script appends placeholder rows to the applicability log, opens a PR titled "third-party/<dep>: sync CVE applicability log" with a body listing the new CVEs. Maintainer reviews, sets bucket and justification, merges. Three matrix jobs run independently (fail-fast: false); a transient API failure for one dep does not block the others. Permissions: contents: write, pull-requests: write at the job level (required so the bot can push the placeholder branch and open the PR via gh). Workflow-level permission is contents: read.
There was a problem hiding this comment.
Attention! This pull request may contain issues that could prevent it from being accepted. Please review the checklist below and take the recommended action. If you believe any of these are not applicable, just add a comment and let us know.
- The PR description does not match the commit message body. This can cause confusion for reviewers and future maintainers. GitHub doesn't automatically update the PR description when you update the commit message so if you've updated the commit with a force-push, please update the PR description to match the new commit message body.
- The are no
cherry-pick-toheaders in any comment in this PR. If the PR applies to more than just the branch it was submitted against, please add a comment with one or morecherry-pick-to: <branch>headers or a comment withcherry-pick-to: noneto indicate that this PR shouldn't be cherry-picked to any other branch. See the Code Contribution documentation for more information.
Documentation:
|
Workflow Check completed successfully |
Member
|
I've placed this into draft for now until I decide whether this is something the project will undertake. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an automated weekly job that diffs published upstream GHSAs against the in-tree CVE applicability logs for each bundled dep in
third-party/versions.mak(pjproject,jansson,libjwt) and opens a PR with pre-populated placeholder rows for any CVE that has no recorded applicability decision.Same shape as Erlang/OTP's
openvex-sync.yml+create-openvex-pr.shrunning against their vendored OpenSSL. Depends on the per-depCVE-APPLICABILITY.mdfiles landing first.Files
How dev effort is minimised on each new CVE
For every newly-published upstream GHSA the bot adds a row to the applicability log. The script does as much of the triage homework as is safely automatable, so the maintainer's manual step shrinks to a confirm-and-justify:
patched_versionsis at-or-before the version pinned inversions.mak, the bot puts the row in the out-of-scope appendix directly. Range-style entries (>= 3.0.0, etc.) stay conservative and land in-scope for manual triage.gh api repos/<upstream>/commits/<sha>and inlinesUpstream fix <sha> touches <files>into the placeholder row. Maintainer doesn't have to hunt for the fix.## In-scope (need triage)from## Out-of-scope (auto-classified, please confirm)so review attention goes to the rows that need it.Behaviour
automated/<dep>-cve-applicability-syncwith the body from the run.fail-fast: false); a transient API failure for one dep does not block the others.Permissions
Job-level:
contents: write,pull-requests: write(required so the bot can push theautomated/<dep>-cve-applicability-syncbranch and open the PR viagh). Workflow-level:contents: read. The elevated permissions are scoped to the single job.Dependencies
Stock GitHub-hosted Ubuntu runner. Python 3.12 via
actions/setup-python@v5; the script uses stdlib only.ghCLI is preinstalled on GitHub runners.Future work (not in this PR)
--disable-*flags inMakefile.rules.git format-patchof the upstream fix) alongside the row update for bucket-4 candidates.