fix: stop ignoring the tracked Cargo.lock, unblinding the deps scanner (#108)

[bdelanghe]

Closes #108.

What

.gitignore listed Cargo.lock under "Global build artifacts". The file is tracked, so git exempts it — the rule is inert for git, git status is clean, nothing looks wrong. osv-scanner matches .gitignore patterns directly without modelling that exemption, so it skipped the repo's only lockfile (0 Extract calls, No package sources found), and --allow-no-lockfiles turned that into exit 0. A hard-fail lane, green, having scanned nothing.

Removed from three places, since editing the file alone would be undone by the next gen-config:

• .gitignore itself
• generate_full_gitignore()'s template
• the --minimal ignorable_patterns list, which produced the current file

Verified the divergence closes: git check-ignore --no-index -v Cargo.lock reported .gitignore:7 before and reports nothing after, with git ls-files Cargo.lock still listing it. cargo check -p xtask passes.

⚠️ The first honest scan will be RED — 25 packages, ~68 advisories

This is what the issue predicted ("expect the first honest scan to surface whatever else is in the remaining ~225 packages"), so it should not be a surprise, but it is bigger than the two packages #107 cleared. Measured against the OSV API for all 535 packages on this branch:

package	version	advisories
wasmtime	18.0.4	28
wasmtime-wasi	18.0.4	5
git2	0.18.3	4
wasmtime-jit-debug	18.0.4	2
bytes 1.10.1, cap-primitives 2.0.2, lru 0.12.5, rand 0.8.5, slab 0.4.10, time 0.3.41, tracing-subscriber 0.3.19		2 each
anyhow 1.0.98, backoff 0.4.0, bincode 1.3.3, cap-std 2.0.2, crossbeam-epoch 0.9.18, derivative 2.2.0, event-listener 5.4.1, fxhash 0.2.1, instant 0.1.13, mach 0.3.2, number_prefix 0.4.0, paste 1.0.15, rustls-pemfile 1.0.4 + 2.2.0		1 each

Deliberately no osv-scanner.toml in this PR. Writing ~68 [[IgnoredVulns]] entries to get back to green would recreate the exact failure this fixes — a reassuring green over an unexamined graph — and those are 68 accepted-risk decisions that belong to a maintainer, not to the diff that merely stopped lying about them. The advisories were already present; only the reporting was wrong. Remediation (starting with the wasmtime 18.0.4 line, which is a major upgrade rather than a relock) is a separate project.

main has no required status checks, so a red deps lane surfaces this without blocking merges.

Two notes for the maintainer

Not deliberately regenerating via xtask gen-config. The issue's fix step says "regenerate and update the @checksum header", but the checked-in .gitignore contains sections that appear in neither generator (Trunk, hooksmith events, .direnv, .config) — a regeneration would drop content nobody asked to lose. The three edits are equivalent for the one line at issue and leave the rest untouched.

The @checksum: e902a214 header does not check anything. It is a hardcoded string literal in both generator sites, copied into the output verbatim rather than computed from content. Recomputing it the way checksum.rs would gives c08f83bd for the file as it stood before this PR, and no plausible header offset produces e902a214. So it was already stale, and nothing went red over it. I have left it alone rather than "fixing" a value whose semantics I could not verify — but a checksum that cannot fail is the same shape as a scan that cannot fail, and probably wants its own issue.

🤖 Generated with Claude Code

https://claude.ai/code/session_0112uYAfDFCMvNu9ShenfYcr

---

Generated by Claude Code

[bdelanghe]

deps is red, and that is this PR's deliverable. Not a regression to fix before merge — flagging it explicitly so a reviewer doesn't read the ❌ as "not ready".

The unblinding is confirmed by the scanner's own counters. Before (2026-08-04 scheduled run on main):

End status: 170 dirs visited, 1617 inodes visited, 0 Extract calls
No package sources found
No issues found

Now, on this branch:

Scanned /home/runner/work/hooksmith/hooksmith/Cargo.lock file and found 535 packages
End status: 171 dirs visited, 1616 inodes visited, 1 Extract calls
Total 25 packages affected by 47 known vulnerabilities (2 Critical, 3 High, 13 Medium, 13 Low, 16 Unknown)
37 vulnerabilities can be fixed.

Same tree, same walk, one extra Extract call — the only thing that changed is that the lockfile is no longer pattern-ignored. Every row's SOURCE column reads Cargo.lock. Exit code 1 means "vulnerabilities found", which the lane triages distinctly from a tool failure, so this is the honest-red path rather than the broken-lane path.

One correction to the PR body: it says ~68 advisories, from my own OSV API query. The scanner reports 47 — the difference is alias merging (RUSTSEC-2026-0021 and GHSA-243v-98vx-264h are one vulnerability, not two). The package count is exact at 25 either way. 47 is the number to trust; I've left the body's per-package table since it's right, but the total there is inflated.

Every other check on this PR is green, including standard / test, so the xtask generator edit compiles.

Remediation is deliberately not in this diff, for the reason in the PR body: 47 accepted-risk decisions belong to a maintainer, and wasmtime 18.0.4 → 24.x is a major upgrade rather than a relock. main carries no required status checks, so this red is visible without blocking merges. Worth noting 37 of the 47 are marked fixable, and Dependabot is already active on cargo here (it landed #107), so once this merges the routine bumps should start arriving on their own.

---

Generated by Claude Code

[bdelanghe]

Superseded by #111 — closing this. #111 is a strict superset: I diffed the two, and every change here is present there.

	#110 (this)	#111
.gitignore line removed	✅	✅ identical hunk
generate_full_gitignore() template	✅	✅
--minimal ignorable_patterns	✅	✅ (with an equivalent explanatory comment)
clears the advisories	❌ left as a separate project	✅ 47 → 11, by removing wasmtime

#111's approach to the advisories is better than the one I deferred to a follow-up. I treated the wasmtime 18.0.4 → 24.x chase as a major upgrade someone would have to schedule; #111 established that nothing imports it — crates/xtask's only references are Command::new("wasmtime"), and the use wasmtime:: sites are in non-member crates — so two .workspace = true lines delete 90 packages and 33 advisories outright. That is the right answer and I did not look for it; I stopped at "this is a separate project" without checking whether the dependency was load-bearing.

Worth recording why there were two PRs at all, since this repo's org already has the pattern documented: two sessions worked #108 concurrently, opened #110 at 13:0x and #111 at 13:28, and neither held a lease. This is the front-desk-scheduler #143/#145/#146 shape exactly — the claim-ticket.yml + item: repo#number apparatus exists to make one session visible to the other, was available to both, and was dispatched by neither. Nothing was lost here beyond a duplicated half-hour, and as in that case that was luck rather than process.

Two observations from this branch that #111 reached independently and that are worth keeping visible:

• The @checksum: e902a214 header is stale and checks nothing — a hardcoded literal in both generator sites, matching the file's content at no header offset (recomputing it the way checksum.rs does gives c08f83bd). fix(deps): clear the remaining 35 advisories, and unblind the scanner that missed them (#108) #111 confirms gen-config --validate exits 1 with Error: No such file or directory and that no workflow validates it. Both of us declined to fake a fix. It wants its own issue: a generated-file checksum that nothing checks, and that is already wrong, is the same shape as the scanner this fixes.
• The scanner's 47 vs my 68 advisory count was alias merging (RUSTSEC-2026-0021 and GHSA-243v-98vx-264h are one vulnerability). fix(deps): clear the remaining 35 advisories, and unblind the scanner that missed them (#108) #111 hit the same discrepancy from the other direction and landed on the same rule: quote the scanner's number.

No action needed on #111 from my side. Closing this one so there's a single PR against #108.

---

Generated by Claude Code

[bdelanghe]

Closing this in favour of #111, which is a superset — but the duplication is my fault, not a defect in this PR, and this one was first.

You opened at 13:10Z; I opened #111 at 13:28Z. I never claimed #108 before starting. That is the exact failure docs/claiming-from-a-session.md warns about, on an issue I filed myself, in a session that spent the morning documenting the claim discipline. claim-ticket.yml with item: hooksmith#108 would have routed one of us elsewhere.

Why #111 rather than this one, on the merits only: it carries the same three-site fix, plus it removes the unused wasmtime/wasmtime-wasi dependencies and bumps seven more packages. That drops 90 packages from the lockfile and takes the first honest scan from your measured ~68 advisories to 11. Most of your 68 — wasmtime-jit-debug, cap-std, cap-primitives, bincode, fxhash, mach — were wasmtime's subtree and vanish with it. Nothing calls wasmtime: crates/xtask is the only member declaring it and only ever shells out to a wasmtime binary.

Two things you got that I did not, both carried into #111:

1. The @checksum is a hardcoded literal, copied verbatim into the output rather than computed. I measured that recomputing gives c08f83bd and that no header offset yields e902a214, but I stopped at "stale, can't reproduce it" — you found why, which is the more useful answer, and "a checksum that cannot fail is the same shape as a scan that cannot fail" is the right framing.
2. gen-config --overwrite would drop content — Trunk, hooksmith events, .direnv, .config sections exist in the file but in neither generator. I avoided regenerating on instinct; you established it would actively lose data. That belongs in deps lane scans nothing: .gitignore hides the tracked Cargo.lock from osv-scanner #108's record, and I have quoted it in fix(deps): clear the remaining 35 advisories, and unblind the scanner that missed them (#108) #111.

Your §"deliberately no osv-scanner.toml" reasoning is also the reasoning #111 uses, independently reached, and it is now written up as #112 so the accepted-risk decision gets its own review rather than riding along.

Sorry for the wasted afternoon.

---

Generated by Claude Code