fix(deps): keep a vulnerable cryptography out of the AGT lock entirely - #158
Merged
Merged
Conversation
The isolation was already right here: AGT resolves in its own venv and an override lifted cryptography afterwards. But that left cryptography 48.0.1 pinned in requirements/agt.txt, and Dependabot flagged it. Fairly: a lock that names a vulnerable version names it whether or not the install order means it ever runs. The lock is now compiled with an override, resolving to cryptography 50.0.1 directly, so there is no vulnerable pin anywhere. The override lives in requirements/agt-overrides.txt, committed, so what is overridden and why stays reviewable. The install needs --no-deps: pip re-resolves even from a fully pinned lock and rejects the override at install time, and the lock already lists every transitive dependency. test_governance_tooling_cannot_downgrade_runtime_dependencies follows the new shape, and its companion now asserts the scanner lock itself carries no cryptography below 50 rather than checking a separate override file. Verified in a clean venv: cryptography 50.0.1 and the agt CLI present. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XbDBXDWWvMFa7c2jGgyq9t
imran-siddique
deleted the
fix/agt-lock-without-vulnerable-cryptography
branch
September 7, 2026 04:33
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
1 participant
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.
Closes the Dependabot alert that appeared once the new
requirements/directory gave it something to scan:Why it was there
AGT caps
cryptographybelow 50.0 through its own dependencies. The isolation was already correct — the scanner resolves in its own.agt-venvand an override lifted cryptography afterwards — so nothing ever ran a vulnerable version.But the lock still named one, and Dependabot is right to flag that. A vulnerable pin in a committed lock is a vulnerable pin, regardless of install ordering, and it would have sat in the alert queue indefinitely.
The fix
The lock is now compiled with
uv pip compile --override, so it resolves tocryptography==50.0.1directly and no vulnerable version appears anywhere.The override lives in
requirements/agt-overrides.txt, committed, with the reasoning and the condition for removing it. That keeps the constraint violation reviewable in a file rather than implied by the ordering of two workflow steps — which I think is the more honest of the two shapes, not just the quieter one.50.0.0 is the first release without PYSEC-2026-3552 and is this runtime's own floor, so AGT's ceiling is stale rather than a real incompatibility.
--no-depsis requiredpip re-resolves even from a fully pinned lock and rejects the override at install time:
The lock already lists every transitive dependency, so there is nothing left for pip to work out. Found the hard way in a clean venv.
Tests
test_governance_tooling_cannot_downgrade_runtime_dependenciesfollows the new shape. Its companion now asserts the scanner lock itself carries no cryptography below 50, rather than checking a separate override file — which is the property that actually matters now.Verified in a clean venv: cryptography 50.0.1,
agtCLI present. 6 passed.🤖 Generated with Claude Code
https://claude.ai/code/session_01XbDBXDWWvMFa7c2jGgyq9t