[chaliy]

What changed

russh 0.65.0 → 0.65.1 and signal-hook 0.4.5 → 0.4.6, recorded as cargo-vet exemptions rather than delta audits. Completes #2880 (its toml/toml_writer half landed in #2884).

Also drops untrusted 0.7.1, which nothing in the graph needs any more.

Why exemptions and not audits

Both crates sit on delta-audit chains whose entries are human source-safety reviews:

• russh: 0.63.3 → 0.64.1 → 0.65.0
• signal-hook: 0.4.4 → 0.4.5

So after the bump cargo vet --locked reported both unvetted and the Audit job failed. You approved taking the bumps without new reviews, and an exemption is precisely what records that: accepted, not audited. An audit entry would instead assert that a source review happened — it didn't, and writing one under your name would be a false attestation in the mechanism that exists to prevent exactly that.

The practical consequence, stated plainly: the audited chains now stop at 0.65.0 / 0.4.5, and these two versions are covered by exemption instead. If you later want them audited, cargo vet certify of the 0.65.0 → 0.65.1 and 0.4.5 → 0.4.6 deltas replaces the exemptions, and cargo vet prune will drop them as unnecessary at that point.

cargo vet diff russh 0.65.0 0.65.1        # 15 files, +388/-49
cargo vet diff signal-hook 0.4.5 0.4.6    # 4 files, +70/-12

Before / After

# Before (the Audit failure on #2880, reproduced locally)
$ cargo vet --locked
Vetting Failed!
2 unvetted dependencies:
  russh:0.65.1 missing ["safe-to-deploy"]
  signal-hook:0.4.6 missing ["safe-to-deploy"]

# After
$ cargo vet --locked
Vetting Succeeded (97 fully audited, 79 partially audited, 586 exempted)

partially audited drops 81 → 79 because these two versions no longer resolve through their delta chains — the visible trace of the audited→exempt swap above.

Risk

• Medium, and worth naming rather than smoothing over: russh is an SSH implementation reached over the network, and this version is now accepted without a source review. That is the trade-off you approved; it is recorded in config.toml where cargo vet surfaces it, not hidden.
• Both are patch releases from the same publishers (Eugeny, vorner).
• Exercised the affected surfaces rather than only building: 24 ssh builtin tests (russh), 152 bashkit-cli tests (signal-hook, interactive), 263 repo-script tests, cargo check --workspace --all-targets clean, cargo vet --locked clean.

Checklist

• cargo vet --locked passes (reproduced the failure first)
• Affected surfaces tested, not just compiled
• Backward compatibility considered — dependency versions only
• CI green — required before merge

Closes #2880.

---

Generated by Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	2835832	Commit Preview URL Branch Preview URL	Nov 07 2026, 05:01 PM

[bashkit-pr-reviewer]

Review summary — chore(deps): bump russh to 0.65.1 and signal-hook to 0.4.6

Verdict: No findings; no review submitted. This is a routine patch-level dependency bump (russh 0.65.0 → 0.65.1, signal-hook 0.4.5 → 0.4.6) with no source-code changes. cargo vet coverage for the resulting graph checks out from the files I could read, and nothing in the change crosses the sandbox boundary or alters behaviour.

Findings by severity: None (no P0/P1/P2).

What I checked beyond the diff:

• Head tree (/workspace/bashkit @ 2835832): Cargo.toml requires russh = "0.65" (satisfied by locked 0.65.1) and signal-hook = "0.4" (satisfied by 0.4.6); russh is wired only through the optional ssh feature as a client, matching the existing audit notes' assumption.
• Cargo.lock: russh 0.65.1's subtree (rand 0.10.3, rand_core 0.10.1, getrandom 0.4.3, generic-array 1.4.5, sha2 0.11.1, sha3 0.12.0, …) is fully covered — exemptions for the exact versions plus delta audits (rand 0.8.7→0.8.8 and 0.10.2→0.10.3, signal-hook 0.4.4→0.4.5, russh chain up to 0.64.1→0.65.0). The lock churn elsewhere is edge rewrites among coexisting, already-exempted versions (windows-sys 0.52.0/0.61.2, syn 2.0.119/3.0.9, getrandom 0.2.17/0.3.4) plus removal of untrusted 0.7.1 (attack-surface reduction, no action needed).
• knowledge/operations/dependencies.md and AGENTS.md reviewed for vet/knowledge-update obligations — nothing in this change makes any knowledge entry stale.

Notes (non-blocking):

• The PR file list names Cargo.toml (+2/−2), but the returned diff (truncated: false) contained only Cargo.lock and supply-chain/config.toml. I verified the head manifest requirements directly instead of reviewing that hunk.
• No delta audits were added for 0.65.0→0.65.1 / 0.4.5→0.4.6 (exemptions only); consistent with a bot PR, and the maintainer's past practice adds delta reviews separately. Stale exemptions for the superseded versions (russh 0.63.3, signal-hook 0.4.4) remain — harmless to cargo vet.
• Could not verify by execution (no cargo/build in this shell, per project review rules): CI's cargo vet --locked and the ssh-feature build remain the backstop, and upstream changelogs for these two patches were inconclusive via web search.

[chaliy]

Thanks — the subtree coverage check is the useful part, since that was the thing I could not verify by inspection alone. Two notes back.

On the file list: there is no Cargo.toml hunk to review. GitHub reports exactly two files for this PR, and neither is a manifest:

Cargo.lock               +15/-23
supply-chain/config.toml +8/-0

git diff --name-only -- Cargo.toml against the parent is empty. So the Cargo.toml (+2/−2) entry wasn't in this PR — flagging it because "I verified the manifest directly instead of reviewing that hunk" could otherwise read as a gap, and there isn't one.

On the superseded exemptions (russh 0.63.3, signal-hook 0.4.4) — those are deliberate, and load-bearing rather than merely harmless.

They are the roots of the delta-audit chains: russh 0.63.3 (exemption) → 0.64.1 → 0.65.0, and signal-hook 0.4.4 (exemption) → 0.4.5. Right now 0.65.1 and 0.4.6 are covered by their own exemptions, so the chains are idle and the roots do look prunable. But the stated path back to an audited chain is for the maintainer to cargo vet certify the 0.65.0 → 0.65.1 and 0.4.5 → 0.4.6 deltas, at which point vetting resolves through the full chain — and a chain needs a root. Pruning now would quietly remove the restore path this PR's description promises.

So they stay until the deltas are certified; cargo vet prune is the right move after that, not before. I also deliberately did not run a blanket prune here for the same reason.

Agreed on everything else, including untrusted 0.7.1 dropping out as attack-surface reduction. Audit has since gone green on this head, which is the check that was failing on #2880.

---

Generated by Claude Code