fix(holdings): refuse a peer-declared address count before reserving on it

[MichaelTaylor3d]

What this is

#1723 — the opcode-222 decode path sized a Vec reservation from the per-change address count the frame declares. Decode runs before verify_holdings_announce, so an unauthenticated peer could commission a ~2 MiB reservation with a ~200-byte frame.

Verdict on the ticket's open question: it is a real defect, not an accepted cost. The u16 does bound it, but the entry is CandidateAddr { host: String, port: u16 } at 32 bytes, so the ceiling is 65,535 × 32 = 2,097,120 bytes — measured, not estimated (see below). Upstream reached the same conclusion independently and clamped it in dig-gossip v0.17.14 (c4630ff, filed there as #1777, a duplicate of #1723). dig-node pinned v0.17.12 and therefore still carried the defect at v0.68.0.

Since the decoder lives in dig-gossip, dig-node cannot host the guard. dig-node's coherent fix is to adopt the release carrying it, and to pin the property with a test so a future rev cannot silently regress it.

Blast radius checked

gitnexus is disabled in the loop (CLAUDE.md §2.0 temp override), so this was done with ripgrep + a direct read at origin/main.

Symbol	Radius
dig_gossip::HoldingsAnnounce::decode	Reached from dig-node at exactly one call site: dig_gossip::holdings_announce_payload, called at holdings.rs:960. No other dig-node path decodes opcode 222.
download::pool_removal_reason	1 production caller (peer.rs:1924 boundary conversion) + 1 test. pub(crate), so the radius is the crate.
download::GossipRemovalReason	Local mirror, pub(crate), constructed only at that one boundary. Adding a variant reaches only the two match sites, both updated.

Nothing on a published API surface changes. Risk: LOW — no HIGH/CRITICAL finding to warn on.

The dependency move

dig-gossip v0.17.12 → v0.17.21 (dd29ce8d). All three pin sites move to the same rev — the dig-gossip dep plus the chia-protocol / chia-sdk-client vendored-fork [patch.crates-io] entries — so the #1529 lockstep holds again instead of straddling two revs. cargo update -p dig-gossip confirms one instance of each resolves.

The v0.17.12..v0.17.21 delta is 5 fixes + 3 docs commits. One of them is source-breaking here: v0.17.15 added PoolRemovalReason::Reaped, which failed the build as a non-exhaustive match.

Reaped folds to Disconnected, deliberately

The selector has no Reaped, so it must fold into one of its three. It folds to Disconnected because a reaped peer's transport was provably closed — a departure — whereas Dead names a keepalive finding a peer unresponsive.

What makes that safe rather than merely tidy: the selector distinguishes only Banned behaviourally (dig-peer-selector-0.7.0/src/engine.rs:467 matches on it alone), treating Disconnected and Dead identically. So the fold is observability-only and cannot change eligibility. Folding it to Banned would have been the real error — it would make an honestly-departed peer ineligible and bias the node toward unremembered peers, which is a sybil. The mapping test now pins the fold so a later edit cannot quietly turn it into that.

How it was verified

The test asserts the ALLOCATION, because the fix is a PLACEMENT

A decoder that reserves first and then fails on the truncated address bytes returns exactly the same None as one that rejects the count up front. assert!(decoded.is_none()) therefore passes against the defect and against the fix — it would pin a coincidence, and a later refactor moving the guard back below the reservation would keep it green. This was not theoretical: in the red run below, the is_none() assertion passed and only the allocation assertion failed.

So crates/dig-node-core/tests/holdings_decode_alloc.rs installs a #[global_allocator] that records the peak single allocation request on the calling thread (thread-local, so concurrent tests in the binary cannot perturb it), and measures it across one call to holdings_announce_payload — dig-node's real inbound seam, not a helper.

The frame is truncated immediately after the declared count. That is what makes it discriminating: with no address bytes present, the only reason a large allocation could appear is the declaration being trusted.

The ceiling (64 KiB) is sized from the protocol, per the ticket's own instruction not to pick a number below the bound: the honest worst case is MAX_ADDRS_PER_CHANGE (32) × 32 bytes, under a kibibyte, and 64 KiB sits ~32× below the ~2 MiB a trusted u16 commits — so the assertion has room for the header's legitimate small allocations while leaving no room for the defect.

Red → green, with only the dep bump between

State	Result
dig-gossip v0.17.12 (commit 1894f7e, test alone)	FAILED — requested 2097120 bytes in a single allocation (ceiling 65536). Exactly the ~2 MiB the ticket predicted.
dig-gossip v0.17.21 (commit 0f5bafa, bump applied)	ok

The test was committed before the fix, so the transition is recorded in history rather than reconstructed — and the only change between the two runs is the dependency rev, which is the isolated-revert proof in the correct order.

Gates

• cargo test --locked — 1193 passed, 0 failed, exit 0. No flakes hit (module_serve::…window_cap and the link.exe 1318 issue both stayed clear).
• cargo clippy --all-targets --locked -- -D warnings — clean.
• cargo fmt --all --check — clean.
• cargo build --locked — real Compiling dig-node-core v0.25.1 line confirmed, so this is not a stale-fingerprint pass.

Version

0.68.0 → 0.68.1 (+ dig-node-core 0.25.0 → 0.25.1). Patch: a compatible security fix. No API removed or renamed, no wire shape changed, and no legitimate frame's treatment changes — dig-gossip has capped both counts at the sender since v0.17.13, so only a crafted frame is affected. #[non_exhaustive]-style breakage does not apply; the extended enum is pub(crate).

SPEC

SPEC.md §19.3a gains the decode-time bound as gate 0 of the ingress ladder. It is stated separately from gate 1 rather than folded into it because it necessarily runs before the signature check — which is precisely why it matters — along with the general rule it instantiates: never size an allocation from a number a peer supplied.

Deliberately not in this PR

• #1668's remaining capability. dig-node's share of #1668 is already landed at origin/main (see the issue comment); the unlanded half is dig-download's paged-prologue reassembly, a different repo. Nothing owed here.
• No superproject edits. SYSTEM.md needs nothing: the contract is unchanged, only the pinned rev enforcing it.

Refs #1723