chore(deps): remove pygments lower bound (intentional routine-test gap) [PYSDK-104]#592
Merged
helmut-hoffer-von-ankershoffen merged 1 commit intomainfrom Apr 25, 2026
Conversation
…ly audit-vulnerabilities routine) [PYSDK-104] Removes the explicit `pygments>=2.20.0` lower bound from pyproject.toml. The bound was added in PYSDK-93 to protect downstream consumers from CVE-2026-4539. Removing it intentionally re-introduces the consumer-side gap so the daily audit-vulnerabilities routine has work to do on its next scheduled run, and we can confirm the routine end-to-end: * detects the missing lower bound for a known accepted CVE * opens a CR ticket and PR per cc-sop-01 / pr-sop-01 * lifts the bound back to >=2.20.0 uv.lock is intentionally NOT modified — pip-audit (which scans uv.lock, not pyproject.toml) will continue to pass. Only the consumer-resolver visibility is reduced. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
helmut-hoffer-von-ankershoffen
added
sop:cc-sop-01
Copilot started reviewing on behalf of
helmut-hoffer-von-ankershoffen
April 25, 2026 09:13
View session
|
There was a problem hiding this comment.
Pull request overview
This PR intentionally removes the published lower-bound constraint for the transitive dependency pygments to create a real downstream-consumer vulnerability detection target for the new scheduled supply-chain audit routine (PYSDK-104), while keeping this repo’s locked dev/CI environment unchanged via uv.lock.
Changes:
- Removed the explicit
pygments>=2.20.0lower bound frompyproject.tomlruntime dependencies. - Synced
uv.locksopygmentsis no longer recorded as a direct requirement, remaining only as a transitive dependency.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
pyproject.toml |
Drops the explicit pygments lower bound from published dependency metadata to reintroduce an intentional downstream gap. |
uv.lock |
Reflects the dependency metadata change by removing pygments from direct requirements while still resolving it transitively. |
Comment on lines
138
to
142
| "lxml>=6.1.0", # CVE-2026-41066 (Renovate #556); also required for python 3.14 pre-built wheels | ||
| "filelock>=3.20.3", # CVE-2025-68146 (>=3.20.1); CVE-2026-22701 (>=3.20.3, Renovate #387) | ||
| "marshmallow>=3.26.2", # CVE-2025-68480 | ||
| "pygments>=2.20.0", # CVE-2026-4539 (>=2.20.0); transitive via rich | ||
| "cryptography>=46.0.7", # CVE-2026-39892 (>=46.0.7); transitive via pyjwt[crypto] | ||
| "pydicom>=3.0.2", # CVE-2026-32711 (>=3.0.2); transitive via dicomweb-client/wsidicom/highdicom |
There was a problem hiding this comment.
With pygments>=2.20.0 removed from the transitive overrides list, the repository documentation becomes misleading: SUPPLY_CHAIN_VULNERABILITIES.md still lists pygments>=2.20.0 as an enforced lower bound. Please add an inline note here that this omission is intentional/temporary (e.g., PYSDK-104 audit-routine test) and/or update the doc table so it accurately reflects the current published constraints.
helmut-hoffer-von-ankershoffen
deleted the
chore/PYSDK-104-remove-pygments-lower-bound
branch
5 tasks
Codecov Report✅ All modified and coverable lines are covered by tests. |
helmut-hoffer-von-ankershoffen
added a commit
that referenced
this pull request
Apr 25, 2026
…YSDK-106] (#594) * chore(ci): emit claude:review:passed/failed label from automated PR review [PYSDK-105] Adds a machine-readable verdict from the automated Claude PR review so branch-protection rules can gate `auto-merge` on the review outcome without human intervention. Changes: * `.github/labels.yml`: two new mutually-exclusive labels - `claude:review:passed` (green) — no blocking findings on current head - `claude:review:failed` (red) — blocking findings on current head * `.github/workflows/claude-code-automation-pr-review.yml`: extend prompt with a mandatory "Machine-Readable Verdict" final step. Claude must emit PASS or FAIL based on the existing CRITICAL CHECKS criteria (test markers, coverage ≥85%, lint clean, conventional commits, architecture/security) and apply the corresponding label via `gh pr edit --add-label ... --remove-label ...`. The opposite label is always removed, so the labels stay mutually exclusive across re-reviews on subsequent pushes. Re-emission: every push to a PR re-runs the review (existing `synchronize` trigger), so the verdict is always tied to the current head commit — stale verdicts cannot persist. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(deps): bump pygments lower bound to >=2.20.0 for CVE-2026-4539 [PYSDK-106] Re-adds the `pygments>=2.20.0` lower bound to `[project].dependencies` transitive overrides in pyproject.toml. The bound was deliberately removed in PYSDK-104 (PR #592) to give the daily audit-vulnerabilities routine a real gap to remediate; this PR closes that gap. The locked version in uv.lock (pygments 2.20.0) already protects our dev/CI env from CVE-2026-4539 (Pygments AdlLexer ReDoS, CVSS 4.8 Medium). This PR closes the remaining downstream-consumer gap so a fresh `pip install aignostics` / `uv add aignostics` / `uvx aignostics` cannot resolve `pygments<2.20.0` transitively via rich. The new lower bound (>=2.20.0) is <= the currently-locked version (2.20.0), so no dependency is upgraded — uv.lock diff is metadata-only (adds the new specifier and the dependency edge); no [[package]] version block changed. Resolves PYSDK-106. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
🛡️ Implements PYSDK-104 — Governed by CC-SOP-01 / PR-SOP-01.
Summary
Removes the explicit
pygments>=2.20.0lower bound frompyproject.toml. The bound was added in PYSDK-93 (#580) to protect downstream SDK consumers from CVE-2026-4539 (transitive viarich). This PR intentionally re-introduces that consumer-side gap so the new dailyaudit-vulnerabilitiesroutine has a real, verifiable detection target on its next scheduled run.Why
We are in the middle of standing up automated supply-chain hygiene via three Claude Code routines (daily + bot-PR triggers). To validate the daily routine end-to-end against production state, we need an actual gap that:
pip-auditdoes NOT flag (becauseuv.lockstill resolves pygments at a safe version transitively), andpyproject.tomlno longer carries the lower bound, leaving downstream consumers exposed).This is the cleanest single-line gap available right now — pygments is purely transitive (via
rich), so removing the explicit bound has no functional impact on this repo's dev/CI environment, only on consumer-resolver visibility.What changed
pyproject.toml: removed"pygments>=2.20.0" # CVE-2026-4539(the line added in PYSDK-93).uv.lock: pre-commit hook auto-synced —pygmentsdrops out of the direct-requires section but stays present transitively viarich.pip-auditcontinues to pass.Expected automated follow-up
Within ~24h the daily audit-vulnerabilities routine should:
pygments>=2.20.0topyproject.tomlwith the CVE annotation.If the routine does not act within the expected window, that is itself the bug — escalate per the audit-vulnerabilities skill's anomaly playbook.
Risk
pip-auditstill passes —uv.lockresolution unchanged at the safe version.Root cause
N/A — intentional, instrumented test of supply-chain automation.
Impact of change
pyproject.toml: one dependency lower bound removed.uv.lock: direct-requires entry forpygmentsremoved; transitive entry retained.pip-auditpasses; lint/test/coverage unaffected.Test plan
make lintgreen locally.git diffconfirms onlypyproject.toml+uv.lockchanged.pygments>=2.20.0.🤖 Generated with Claude Code