[bkataru]

Advances #83. Cargo.lock only — 3 version lines, no manifest changes.

What this clears

crate	bump	clears	reaches
crossbeam-epoch	0.9.18 → 0.9.21	RUSTSEC-2026-0204	pawan-core via deagle-parse; pawan-cli via termimad
h2	0.4.13 → 0.4.16	RUSTSEC-2026-0258	pawan-core + pawan-cli via reqwest → active
quinn-proto	0.11.14 → 0.11.15	RUSTSEC-2026-0185	nothing (orphan)

cargo audit on this lockfile reports 4, down from 7.

The h2 finding

There are two h2 copies in the lockfile on different paths. #81 correctly says h2 is blocked by rs-utcp pinning tonic ^0.11 — but that only covers one of them:

h2 0.3.27  <- hyper 0.14 -> tonic 0.11 -> rs-utcp -> thulp-mcp -> pawan-mcp   (legacy, blocked)
h2 0.4.13  <- hyper 1.9  -> hyper-rustls -> reqwest -> pawan-core, pawan-cli  (active, fixable)

cargo update -p h2@0.4.13 --precise 0.4.16 succeeds; the same command on 0.3.27 fails with required by reqwest = "^0.11" of rs-utcp v0.3.2, exactly as #81 predicts. So #81's scope is right but incomplete — the active-path copy was never blocked and needed no upstream change.

quinn-proto is an orphan

cargo tree -i quinn --edges all --target all reports nothing to print, and no workspace Cargo.toml mentions quinn. It is advisory-bearing weight nothing pulls in. Bumping clears the advisory; the honest fix is pruning it from the lockfile. Flagging for whoever knows why it is there.

Deliberately not included

quick-xml 0.39.2 → 0.39.4 resolves cleanly but still fails RUSTSEC-2026-0194/0195 — patched is >=0.41.0, capped by plist 1.9.0. Pure churn, so it is not in this diff.

Verification

cargo check --workspace --all-targets   -> Finished, exit 0
cargo audit                             -> 4 vulnerabilities (was 7)

Reachable from production crates (pawan-core, pawan-api, pawan-cli), not just the workspace.

Sequencing — needs a decision

#82 (rustls) is open right now and touches the same Cargo.lock. main is still at de893a9, so whichever merges first needs the other rebased. This one is compiled and unblocked; #82 additionally needs rustls 0.23.45.

Landing this first makes the audit gate less red for #82 to land against. Merge order is the operator's call, not mine.

Remaining 4 after both: quick-xml ×2 (blocked by plist), h2 0.3.27 (blocked by rs-utcp, #81), rustls (#82).

[bkataru]

Correction to my own description: the diff is 48 lines, not 3 — and I cannot explain the socket2 churn

Verifying this PR against a fresh run rather than trusting my earlier numbers, and my description understates the change. Correcting it before anyone reviews it on a false premise.

What holds

• 7 → 4 advisories, re-measured just now: cargo audit on origin/main:Cargo.lock → 7 vulnerabilities; on this branch → 4 vulnerabilities. Both 7 allowed warnings.
• No manifest change. git diff --stat origin/main <branch> → Cargo.lock | 48 +++---, 1 file changed.
• Package set unchanged: 852 entries on both sides. 949 (name, version) pairs on both sides; exactly 6 differ, i.e. exactly the 3 packages claimed (crossbeam-epoch 0.9.18→0.9.21, h2 0.4.13→0.4.16, quinn-proto 0.11.14→0.11.15).

So "3 version lines, no manifest changes" is right about what moved and wrong about how big the diff is.

What I cannot explain

The 48 lines are 3 version lines, 3 checksums, and ~21 dependency-edge rewrites. Among them, packages at identical versions resolve a different socket2:

             main                this branch
hyper-util   socket2 0.6.3   ->  socket2 0.5.10
quinn        socket2 0.6.3   ->  socket2 0.5.10
quinn-udp    socket2 0.6.3   ->  socket2 0.5.10
tonic 0.14.5 socket2 0.6.3       socket2 0.6.3   (unchanged)

Both socket2 0.5.10 and 0.6.3 are present as packages in both lockfiles; only the edges moved. A targeted cargo update -p <pkg> --precise <ver> should not re-resolve unrelated edges, and I have not determined why this one did.

I checked whether the lockfile is at least self-consistent rather than leaving that open too:

• cargo metadata --locked passes on this branch against this branch's manifests (exit 0).
• Control: pointing quinn-udp at a nonexistent socket2 9.9.9 fails correctly (exit 101). The check can fail, so the green above is meaningful.
• Branch base is current with main (de893a97, 0 commits behind), so this is not stale-tree drift.

I am not claiming the churn is benign. It is internally valid and it does not change which packages are present, but an unexplained re-resolution in a diff whose entire purpose is "three targeted advisory bumps" is the kind of thing a reviewer should look at rather than take on trust. If the intent is a minimal lockfile diff, regenerating with a narrower command and confirming the edge set is unchanged would be the way to settle it.

Net effect on the PR's value is unchanged: cargo audit on this lockfile reports 4, down from 7. Still BLOCKED by two pre-existing red gates on main (#86 clippy, #83 audit), neither caused by this diff.

[bkataru]

Resolved: the lockfile is clean, and the socket2 churn is caused by the h2 bump alone

My previous comment left the churn unexplained and said I was not claiming it benign. I ran the experiment to find out, and the answer is better than "benign" — the diff is exactly what the three commands produce, and one bump causes the rest.

1. My lockfile is byte-identical to a clean regeneration

Started from origin/main's untouched Cargo.lock (md5 38e7a362…) and ran only the three targeted bumps:

cargo update -p crossbeam-epoch --precise 0.9.21
cargo update -p h2@0.4.13        --precise 0.4.16
cargo update -p quinn-proto      --precise 0.11.15

Result md5 c315604c… is identical to this PR's actual Cargo.lock. So there is no stray re-resolution, no stray crate, nothing hand-edited. The diff is reproducible from main by the documented commands, which is the property a lockfile bump needs to have.

cargo audit on that clean regeneration: 4 vulnerabilities (from 7), same as this branch.

2. The h2 bump alone accounts for the socket2 movement

I isolated each bump individually, restoring main's lockfile before each, and recorded which packages resolve socket2 0.5.10:

after bumping	consumers of socket2 0.5.10
crossbeam-epoch only	hyper, webrtc-mdns
h2@0.4.13 only	hyper, hyper-util, quinn, quinn-udp, webrtc-mdns
quinn-proto only	hyper, webrtc-mdns

h2 0.4.16 requires a newer socket2 than 0.4.13 did, so the resolver unified the whole h2/hyper/quinn subtree onto 0.5.10. Line counts agree: h2 alone → 40 changed lines; all three → 48. The remaining 8 are the two version+checksum pairs for crossbeam-epoch and quinn-proto.

So the ~21 "unrelated" edge rewrites are not unrelated — they are the downstream consequence of the one advisory fix that matters most (h2 0.4.13 is the active reqwest path into pawan-core/pawan-cli, per my original note).

Correction to my own framing

I wrote "I am not claiming the churn is benign" and left it open. That was the honest state at the time — I had verified self-consistency but not cause. Having now established cause, the accurate statement is: the churn is required by the h2 fix, not incidental to it. The earlier caution was right to withhold a claim I could not yet support; it should not be read as a standing reservation.

Net: cargo audit reports 4, down from 7. Still BLOCKED by two pre-existing red gates on main (#86 clippy, #83 audit), neither caused by this diff. No push, no merge, no force-push from me.

[bkataru]

Retracting my socket2 explanation — it was correlation, not mechanism

My third comment claimed the h2 bump caused the socket2 re-resolution ("h2 0.4.16 requires a newer socket2"). That is refuted. I checked the crate manifests directly:

$ tar xzf h2-0.4.16.crate && grep socket2 h2-0.4.16/Cargo.toml   →  (no match)
dependency-name diff between 0.4.13 and 0.4.16: none
socket2 in either version: False

h2 does not depend on socket2 at all, in either version. There is no edge for a bump to move. Withdrawing that explanation.

What is actually happening

h2 alone (cargo update -p h2@0.4.13 --precise 0.4.16) changes 2 lines: its own version and checksum. Every other changed line is a dependency reference — and no package version changed anywhere:

windows-sys versions present, before: 0.48.0 0.52.0 0.59.0 0.60.2 0.61.2
windows-sys versions present, after:  0.48.0 0.52.0 0.59.0 0.60.2 0.61.2   (identical)

The reference multiset is what moves:

                       before            after
"windows-sys 0.61.2"    21    →           9
"windows-sys 0.60.2"     3    →           6
"socket2 0.5.10"        2    →           5
"socket2 0.6.3"         5    →           2

So cargo is re-resolving which of several already-present duplicate versions each dependent binds to — it is not adding, removing, or upgrading anything. socket2 0.5.10 and 0.6.3 both exist in the file before and after; what changed is which packages point at which.

That is consistent with the lockfile being written by a resolver pass that is free to pick among duplicates already in the graph, and it is not attributable to the security fix itself. My isolation table earlier — "h2 alone → 40 lines" — was arithmetically right and mechanistically wrong, and I read the line count as causation.

What this does and does not change

• The PR's substance is unaffected. cargo audit reports 4 on this lockfile versus 7 on origin/main, measured with main's own .cargo/audit.toml from a neutral directory. crossbeam-epoch, h2 0.4.13, quinn-proto cleared.
• The lockfile is still reproducible: main + the three documented --precise commands yields this file byte-for-byte (md5 c315604c…), which is the property that matters for review.
• What I withdraw is the causal claim. A reviewer wanting a minimal diff should know the 38 non-h2 lines are resolver reassignment among pre-existing duplicates, not a consequence of the advisory fix — and that regenerating with a narrower command may not remove them, since they appear to follow from any re-resolution pass.

I have now corrected this thread three times (diff size, then mechanism, now cause). Each correction came from reading the artifact rather than reasoning about it; the first two rounds I should have read h2's manifest before proposing a mechanism at all.

[bkataru]

Correction: this PR clears two advisories, not three — and my own earlier comment on #83 said four were mechanical

The title said "7 -> 4" and "3 advisories", and I have separately told you on #83 that "quinn-proto, quick-xml ×2, and crossbeam-epoch are ordinary lockfile bumps". That was wrong, and this PR is where the error becomes visible.

What this PR actually clears

Cargo.lock only, three version lines:

package	from	to	advisory	verdict
crossbeam-epoch	0.9.18	0.9.21	RUSTSEC-2026-0204 (>=0.9.20)	cleared
quinn-proto	0.11.14	0.11.15	RUSTSEC-2026-0185 (>=0.11.15)	cleared
h2	0.4.13	0.4.16	RUSTSEC-2026-0258 (>=0.4.16)	half — 0.3.27 remains

So: two advisories fully cleared, and a third partially. Not three.

The h2 row is the one worth reading twice

Cargo.lock carries two h2 entries. This PR moves the one it can:

at PR head 98a399d:
  h2 0.3.27    <- still vulnerable
  h2 0.4.16    <- clean

0.3.27 cannot move: rs-utcp pins tonic ^0.11, which resolves that h2 — see #81. So RUSTSEC-2026-0258 still fires after this PR, on one crate, and it will keep firing until #81 unblocks. Anyone counting advisories after merging should expect 0258 to remain; it is not an oversight in this diff.

Measured, not arithmetic

I got the "cleared" count wrong by reading versions by eye earlier. Both refs through cargo audit --json, counting both channels (warnings were 0 in both, so no second-channel contribution):

main de893a9 : 7 rows / 6 distinct   exit 1
   0185 0194 0195 0204 0258 0285

head 98a399d : 4 rows / 4 distinct   exit 1
   0194 0195 0258 0285

CLEARED       : 0185, 0204
NEW/REGRESSED : none

7 → 4 rows is right, and that is why the old title was not obviously wrong. But rows and advisories are different units: main's 7 rows cover only 6 advisories because h2 contributes two rows to one id. Reporting "3 advisories cleared" against a 7→4 row drop does not survive the instrument.

quick-xml is deliberately absent — and it is not mechanical

0194 and 0195 (quick-xml 0.39.2, >=0.41.0) are not in this PR, and should not be. 0.39.2 → 0.41.0 is two minor versions — a semver-breaking boundary — versus the patch moves here. I have not tested whether that break affects pawan, so I am not proposing it.

Unchanged

main still fails -D warnings for an unrelated reason (#86), and rustls/0285 remains the "needs discussion" row. This PR is Cargo.lock only, compiles, and introduces no new advisory.

Correcting the record because #83's comment told you to plan around a wrong number. No lockfile edit, no commit, no push, no claim.

[bkataru]

Subsumed by a single verified lockfile, posted on #83. This PR's CI cannot go green on its own: cargo audit fails on advisories outside its scope, and Check & Lint fails on clippy::double_must_use. Combining this bump with async-trait 0.1.92 + rustls 0.23.45 + quinn-proto 0.11.15 + crossbeam-epoch 0.9.20 + h2 0.4.16 + plist 1.10.1 takes the gate from 7 vulnerabilities to 1 with clippy exit 0 and 1826/1826 nextest green (lockfile sha 9dc234af6eba1997, lint result carries a planted-violation control at exit 101). No new PR opened — this needs review, not re-derivation. One caveat: h2 0.3.27 remains and no lockfile can clear it (see #81).

[bkataru]

Rebasing this branch onto current main leaves it with no diff at all: git reported 39 of its
commits as previously applied upstream and skipped them, and its lockfile-bump commit became
empty against the current lockfile - main already carries the versions it moved to.

So there is nothing left here to review, and the advisory work this was opened for is carried by
#82, whose measured bump set clears eleven of the fourteen findings cargo audit reports with the
repository's suppressions applied.

Closing as superseded. The branch stays on the remote and every commit in it is already in
main, so nothing is lost.