Skip to content

osv-scanner: time-boxed ignores for the 2026-09-29 oauthlib/PyJWT advisories (unblocks the required check) - #517

Merged
seathatflowsinourveins merged 3 commits into
mainfrom
claude/osv-oauthlib-pyjwt-20260929
Sep 29, 2026
Merged

osv-scanner: time-boxed ignores for the 2026-09-29 oauthlib/PyJWT advisories (unblocks the required check)#517
seathatflowsinourveins merged 3 commits into
mainfrom
claude/osv-oauthlib-pyjwt-20260929

Conversation

@seathatflowsinourveins

@seathatflowsinourveins seathatflowsinourveins commented Sep 29, 2026

Copy link
Copy Markdown
Collaborator

Scope

This unblocks the required osv-scanner check, which has failed on every new PR head since three Medium advisories were published on 2026-09-29. CI runs 36613233591, 36617653508 and 36618373159 all failed on the same five findings.

  • Lane: lane:shared. It widens the trading-owned Lumibot lock allowance in tests/test_osv_lockfile_coverage.py, so the trading lane's acknowledgement is needed.
  • It adds three [[IgnoredVulns]] entries to .github/osv-scanner.toml, each with ignoreUntil = 2026-10-13 (14 days, well under the 90-day cap) and a concrete non-reachability reason:
    • GHSA-hj66-6f7g-4r5v: oauthlib <= 3.3.1, RevocationEndpoint JSONP when enable_jsonp=True; fixed in 4.0.0.
    • GHSA-xpv3-w29h-x7cv: oauthlib >= 3.0.0 < 4.0.0, PKCE code_verifier comparison timing; fixed in 4.0.0.
    • GHSA-w6j9-cwv2-h6wq: PyJWT 2.9.0 to 2.13.0, a malformed RSA JWK aborts a JWK Set parse; fixed in 2.14.0.
  • IGNORE_ALLOWED_LOCKS changes:
    • blueprints/runtime-workers/openhands/requirements.lock is added, pinned at sha256 02d0a7f0….
    • The frozen …/spy-one-zero-20260926/lumibot/lockcheck/lumibot.lock entry gains the two oauthlib advisories. It pins PyJWT 2.15.0, which is already fixed.
  • The same entries go into docs/decisions/2026-09-22-github-automation-closure.md, with the new receipt evidence/receipts/osv-oauthlib-pyjwt-reachability-20260929.json.

Reachability evidence (a static search, recorded in the receipt):

  • All 336 OpenHands and 263 Lumibot lock artifacts were downloaded and hash-checked against their locks, then searched.
  • enable_jsonp and oauthlib's server grant and endpoint modules have 0 hits in both.
  • The only oauthlib importers are requests-oauthlib's client classes and a kubernetes exception import.
  • The RevocationEndpoint and AuthorizationCodeGrant hits are Authlib's own code, which never imports oauthlib.
  • PyJWKSet and PyJWK appear only under litellm/proxy/, and PyJWKClient only in google-auth id_token.py:144, which none of the other artifacts calls.
  • The recipe and trial code have 0 hits.

Expiry plan (the ignores apply repo-wide by id, so every PR fails again on 2026-10-13 unless one of these lands first):

  • The OpenHands lock owner (token-save-practice-e2e-status) relocks onto oauthlib 4.0.0 and PyJWT 2.14.0, and in the same PR deletes the OpenHands allowlist entry and the PyJWT ignore.
  • The frozen Lumibot lock gets either a renewed, dated reason for the two oauthlib ignores or deletion.

SOTA sources

  • osv-scanner v2.6.0 (osv-scanner_linux_amd64 sha256 ca69b3d3cd08f889a49dc0a383122f71cc528b83803671df5fd874d97485b108), the workflow's pinned release, run locally exactly as .github/workflows/security-scan.yml runs it.
  • GitHub Advisory Database and osv.dev records for GHSA-hj66-6f7g-4r5v, GHSA-xpv3-w29h-x7cv and GHSA-w6j9-cwv2-h6wq, read 2026-09-29.
  • The repository's ignore policy: .github/osv-scanner.toml header, tests/test_osv_lockfile_coverage.py and docs/decisions/2026-09-22-github-automation-closure.md.
  • The PyPI artifact hashes listed in the receipt.

Evidence-class table

Evidence Class Result
osv-scanner before and after upstream-unchanged Before (ed29398): exit 1, "5 known vulnerabilities (0 Critical, 0 High, 5 Medium)". After: exit 0, "No issues found".
Coverage test with negative control our-integration 30 OK. Removing the allowlist reports exactly the 7 affected pins, and a changed digest is caught.
Full suite our-integration 7,606 OK, skipped=780

Local commands run

  • python3 -m unittest tests.test_osv_lockfile_coverage: exit 0, Ran 30 tests, OK.
  • python3 scripts/validate.py: exit 0, "status": "passed".
  • scripts/git-hooks/pre-push: 3 OK.

Decision record

docs/decisions/2026-09-22-github-automation-closure.md: one dated entry per ignore, with evidence and expiry plan.

Host evidence

None.

Checklist

  • An independent verification ran in parallel with CI. There was no GPT-6 review, because Codex capacity is reserved for the Gate A reviews.
  • This is urgent: every PR's required check fails until it merges.

🤖 Generated with Claude Code

Scout and others added 2 commits September 29, 2026 15:22
Scout @claude
osv: ignore the 2026-09-29 oauthlib and PyJWT advisories for two revi…
1928911 
…ewed locks

GHSA-hj66-6f7g-4r5v and GHSA-xpv3-w29h-x7cv (oauthlib 3.3.1, fixed in 4.0.0)
and GHSA-w6j9-cwv2-h6wq (PyJWT 2.13.0, fixed in 2.14.0) were published on
2026-09-29. Since then every pull_request run of the required osv-scanner
check has failed (runs 36613233591, 36617653508 and 36618373159) with five
Medium findings: all three advisories in
blueprints/runtime-workers/openhands/requirements.lock and the two oauthlib
ones in the frozen Lumibot lock of the SPY one_zero engine trial.

Neither lock is relocked here. The Lumibot lock is a frozen evaluation record,
and the OpenHands lock is a live recipe whose owner relocks it. Each advisory
gets an [[IgnoredVulns]] entry until 2026-10-13. IGNORE_SCOPES names the fixed
versions, and IGNORE_ALLOWED_LOCKS allows the two locks at their reviewed
sha256. The Lumibot entry now names the new record as its evidence, and that
record carries forward the 2026-09-26 nltk and setuptools review.

The non-reachability review
(evidence/receipts/osv-oauthlib-pyjwt-reachability-20260929.json) searched
every hash-verified artifact of both locks:
- Nothing constructs an oauthlib RevocationEndpoint with enable_jsonp, and
  nothing imports oauthlib's grant types, endpoints or servers.
- PyJWT's JWK Set API appears only in the LiteLLM proxy server and in
  google-auth's ID-token verification. The recipe runs neither, and no
  installed package calls them.

The closure decision record lists each entry with its evidence and expiry
plan. On 2026-10-13 the scan fails again on the Lumibot lock by design.

Local runs of the CI scan command (pinned OSV-Scanner 2.6.0, sha256-checked):
- before, exit 1: "Total 3 packages affected by 5 known vulnerabilities
  (0 Critical, 0 High, 5 Medium, 0 Low, 0 Unknown) from 1 ecosystem."
- after, exit 0: "No issues found".

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Scout @claude
manifests: register the osv oauthlib and PyJWT ignore change
770d67d 
Hot-file protocol (docs/lanes.md): re-registers the three changed registered
files and adds the new evidence record:
- .github/osv-scanner.toml
- docs/decisions/2026-09-22-github-automation-closure.md
- tests/test_osv_lockfile_coverage.py
- evidence/receipts/osv-oauthlib-pyjwt-reachability-20260929.json (new)

Registration used host_receipts.register_file. component_matrix.py --write and
new_host_grand_list.py --write left their reports unchanged. validate.py
passed with 8157 hashed files.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
@seathatflowsinourveins seathatflowsinourveins added the lane:shared Touches files owned by both lanes; needs both lanes' acknowledgement label Sep 29, 2026
@seathatflowsinourveins

seathatflowsinourveins commented Sep 29, 2026

Copy link
Copy Markdown
Collaborator Author

Trading lane acknowledgement (docs/lanes.md:146-149). Reviewed at head 770d67db by ecosystem-roadmap-2026, which holds the trading lane.

  • Scope check. The three ignores match by id repo-wide. The coordinator searched every lock and requirements file under blueprints/us-equities/ and catalogs/us-equities/ at main. Only engine-trials/spy-one-zero-20260926/lumibot/lockcheck/lumibot.lock pins oauthlib or PyJWT, so no live trading lock is silenced. The paper engine's runtime (alpaca-py, nautilus-trader) pins neither.
  • The Lumibot lock is a frozen engine-trial record, and it stays byte-identical. The reachability receipt's 0-hit evidence and the 2026-10-13 expiry are accepted. The trading lane will renew with a dated reason or delete the lock at expiry. The lane's own Lumibot comparison is done; LEAN is the frozen oracle.

No objection.

@seathatflowsinourveins seathatflowsinourveins mentioned this pull request Sep 29, 2026
Open
Scout @claude
osv ignore reason: state GHSA-xpv3's range as the record does (>= 3.0…
77480db 
….0, < 4.0.0) and pair lines 49/61 with s256/plain (verifier D1, D2)

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
@seathatflowsinourveins

seathatflowsinourveins commented Sep 29, 2026

Copy link
Copy Markdown
Collaborator Author

Head moved from 770d67db (trading-acknowledged above) to 77480dbc, and the delta is prose only: git diff 770d67db 77480dbc touches .github/osv-scanner.toml (the GHSA-xpv3 reason now states the record's range ">= 3.0.0, < 4.0.0" and pairs line 49/61 with s256/plain) and its manifests/evidence.json hash. The fix follows the independent verifier's defects D1 and D2. The Lumibot allowance, both locks and tests/test_osv_lockfile_coverage.py are unchanged, so the acknowledged trading-owned content is identical. Verifier: 8/8 claims confirmed; after the fix tests.test_osv_lockfile_coverage is OK and validate.py passed.

@seathatflowsinourveins
seathatflowsinourveins merged commit b95f575 into main Sep 29, 2026
25 checks passed
@seathatflowsinourveins
seathatflowsinourveins deleted the claude/osv-oauthlib-pyjwt-20260929 branch September 29, 2026 20:31
seathatflowsinourveins pushed a commit that referenced this pull request Sep 29, 2026
Scout
Merge origin/main (osv ignores, #517) into the U1 branch
2cb5be5
seathatflowsinourveins pushed a commit that referenced this pull request Sep 29, 2026
Scout
Merge origin/main (osv ignores, #517) into the U13 branch
ee9b2ff
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

lane:shared Touches files owned by both lanes; needs both lanes' acknowledgement

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@seathatflowsinourveins