Repository navigation
build: commit uv.lock so dependabot can see what is resolved - #45
Merged
Merged
Conversation
uv.lock has been gitignored since the scaffold (90d7c39), while .github/dependabot.yml says the lockfile is committed and that the lock is what its uv ecosystem updates. With no lock on main, Dependabot's uv updater and its security alerts saw only the ranges in pyproject.toml, and CI resolved whatever was current on each run. A quiet alert list here said nothing about the installed versions. The lock is generated fresh with `uv lock --upgrade`. Hatch's sdist takes every file that is not gitignored, so `uv.lock` is excluded from it, as partspec does: the sdist file list is identical to main's (97 files). With the exclude removed, the sdist gains uv.lock, so the exclude is what holds it out. OSV querybatch over the 39 pinned packages: no records. just check: clean. just test: 252 passed, 12 skipped (no KiCad here).
This was referenced Oct 31, 2026
CameronBrooks11
added a commit
to heibench/orlab
that referenced
this pull request
Oct 31, 2026
Pilot for a lockfile audit in every repo with a committed `uv.lock`. Once the shape is agreed here, I'll copy it to partspec, gerberdiff, slicelab, prusaslicer-py and netspec. **Why:** Dependabot alerts missed vulnerable pins in this org: certifi 2026.5.20 in gerberdiff and msgpack 1.2.1 in partspec (CVE-2026-114613) had no alert, and netspec's lock wasn't committed at all until heibench/netspec#45. An empty alert list isn't evidence that a lock is clean. An OSV query over the committed lock caught all three. **What** - `just audit`: `uv audit --frozen --preview-features audit-command`. That's uv's own OSV audit over every package in `uv.lock`, extras included, with nothing new to install. `--preview-features` opts in to the experimental command. - `.github/workflows/audit.yml`: runs `just audit` daily, on dispatch, and on PRs touching `uv.lock`, `pyproject.toml`, the `justfile` or the workflow itself. - If a scheduled or dispatched run fails, a separate `file-issue` job (`issues: write`; the audit job is `contents: read`) opens an `audit` issue, or comments on the one already open. It creates the label itself. PR runs only report on the PR. **Not in `just check` or the required `ok` gate, on purpose:** advisories land while nothing in the repo changes (msgpack's did), and in the gate one would turn every unrelated PR red. **Evidence (local)** - Current lock: `Found no known vulnerabilities ... in 56 packages`, exit 0. - Lock from before #79 (pillow 12.3.0, certifi 2026.6.17): `Found 61 known vulnerabilities ... in 64 packages`, exit 1. (61 vs the 42 Dependabot alerts: OSV lists GHSA and PYSEC ids for the same advisories.) - Extras: on partspec's pre-#427 lock, it found msgpack, which only arrives through an optional extra. - `just check`: clean. `just test`: 235 passed, 2 skipped (pandas not in the dev group). **Not verified:** the `file-issue` path, which only runs after a failed audit. This PR's own `audit` run exercises the audit job only. To test the issue path after merge, dispatch the workflow on a branch with a vulnerable lock. **Risk:** `uv audit` is experimental. If uv changes its interface, the job fails, and the scheduled failure files an issue saying so.
CameronBrooks11
added a commit
that referenced
this pull request
Oct 31, 2026
Dependabot alerts missed vulnerable pins in this org (certifi in gerberdiff, msgpack in partspec), so an empty alert list is not evidence the lock is clean. `just audit` runs uv's `uv audit --frozen` over every package in uv.lock, extras included; audit.yml runs `just audit` daily, on dispatch, and on PRs touching the lock, pyproject, the justfile or the workflow. A scheduled or dispatched failure opens or comments on one `audit` issue. It stays out of `just check` and the required `ok` gate, where an upstream advisory would turn every unrelated PR red. Same shape as heibench/orlab#84. Measured locally: exit 0 on this lock (39 packages); no vulnerable lock in this repo's history to show it red on (the lock was first committed in #45); the same recipe goes red on partspec's and gerberdiff's. just lint, typecheck: clean. just test: 252 passed, 12 skipped (no KiCad here). `ruff format --check .` failed locally on unreadable device nodes under .claude/ in my checkout, not on repo files; over the tracked files it reports 50 already formatted.
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.
uv.lockhas been gitignored since the scaffold (90d7c39)..github/dependabot.ymlsays the opposite: "the lockfile is committed, so the lock is the thing that needs updating". With no lock onmain, Dependabot'suvupdater and security alerts only ever saw the ranges inpyproject.toml, and CI resolved whatever was newest on each run. So netspec's empty alert list never said anything about the versions actually installed.Changes
.gitignore: stop ignoringuv.lock.uv.lock: generated fresh withuv lock --upgrade(39 pinned packages).pyproject.toml:[tool.hatch.build.targets.sdist] exclude = ["uv.lock"]. Hatch's sdist takes every non-ignored file, so without this the lock would start shipping. partspec excludes its lock for the same reason.Evidence
mainvs this branch: identical (97 files). With the exclude removed, the sdist gainsuv.lock, so the exclude is what holds it out.querybatchover all 39 pinned versions: no records.just check: clean.just test: 252 passed, 12 skipped (KiCad not installed locally).just setupstaysuv sync --all-extras, so CI now installs from the lock. If you'd rather CI fail on a stale lock, as prusaslicer-py does with--locked, that's a separate change.