Problem Statement
The repo has 9 separate uv.lock files (root + 7 servers + auth_server + metrics-service + agents/a2a). Keeping them in sync with the latest secure dependency versions is tedious to do by hand: you'd have to cd into each directory and run uv lock --upgrade, and there's no built-in defense against pulling a brand-new (potentially compromised) package version that hasn't yet been vetted by the security community.
Proposed Solution
Add a make uv-update-locks target that:
- Walks every
uv.lock in the repo (skipping .venv/ and node_modules/)
- Runs
uv lock --upgrade in each directory
- Uses
UV_EXCLUDE_NEWER (a uv env var) to exclude package versions published in the last N days (default 7), giving the security community time to flag and yank malicious or broken releases before they get locked into the project
Usage
make uv-update-locks # default 7-day quarantine
make uv-update-locks UV_EXCLUDE_NEWER_DAYS=14 # 14-day quarantine
Why the quarantine?
This is a supply-chain security mitigation. Compromised packages (typosquats, malicious updates) often get caught and yanked from PyPI within hours-to-days of publication. By excluding versions newer than 7 days, the project avoids pulling a newly-compromised package before the community has had a chance to react.
User Stories
- As a maintainer, I want a single command that refreshes all
uv.lock files so I don't have to walk every directory manually.
- As a security-conscious operator, I want the default refresh to skip recently-published versions so a compromised package doesn't get pinned into our locks before the community catches it.
- As a release engineer, I want the quarantine window to be configurable (e.g.
UV_EXCLUDE_NEWER_DAYS=14) for stricter or more permissive policies.
Acceptance Criteria
Out of Scope
- Automated weekly/monthly runs via GitHub Actions (manual trigger only for now)
- Per-package version pinning policies
- Dependabot integration
Related
Problem Statement
The repo has 9 separate
uv.lockfiles (root + 7 servers + auth_server + metrics-service + agents/a2a). Keeping them in sync with the latest secure dependency versions is tedious to do by hand: you'd have tocdinto each directory and runuv lock --upgrade, and there's no built-in defense against pulling a brand-new (potentially compromised) package version that hasn't yet been vetted by the security community.Proposed Solution
Add a
make uv-update-lockstarget that:uv.lockin the repo (skipping.venv/andnode_modules/)uv lock --upgradein each directoryUV_EXCLUDE_NEWER(auvenv var) to exclude package versions published in the last N days (default 7), giving the security community time to flag and yank malicious or broken releases before they get locked into the projectUsage
Why the quarantine?
This is a supply-chain security mitigation. Compromised packages (typosquats, malicious updates) often get caught and yanked from PyPI within hours-to-days of publication. By excluding versions newer than 7 days, the project avoids pulling a newly-compromised package before the community has had a chance to react.
User Stories
uv.lockfiles so I don't have to walk every directory manually.UV_EXCLUDE_NEWER_DAYS=14) for stricter or more permissive policies.Acceptance Criteria
make uv-update-locksruns from the repo root and processes everyuv.lockin the repoUV_EXCLUDE_NEWER_DAYSenv var overrides the window (e.g.UV_EXCLUDE_NEWER_DAYS=14).venv/andnode_modules/directoriesdate -u -v-Nd) and Linux (date -u -d 'N days ago')uv.lockfiles (./uv.lock,auth_server/uv.lock,agents/a2a/uv.lock,metrics-service/uv.lock,servers/*/uv.lock) are refreshedmake helpmentions the new targetMakefile(ordocs/) explains the supply-chain quarantine rationaleOut of Scope
Related