chore: drop sigp libp2p fork patches, follow upstream

[shane-moore]

Problem

Anchor's [patch.crates-io] redirected libp2p + 5 sub-crates to sigp's rust-libp2p@defcaf1a fork. Maintaining a fork rev is friction, and we can drop it now.

Why we can drop the patches

All four gossipsub deltas the fork carried are now upstream:

• PRUNE backoff Duration overflow (GHSA-gc42-3jg7-rxr2) → upstream gossipsub 0.49.3.
• PRUNE backoff Instant overflow (GHSA-xqmp-fxgv-xvq5) → upstream gossipsub 0.49.4 via libp2p/rust-libp2p#6359.
• IWANT and IDONTWANT control-message bounds → upstream via libp2p/rust-libp2p#6409 (merged 2026-05-05). Replaces the fork's per-IWANT/IDONTWANT handler-time inner caps with a unified codec-time max_control_messages cap covering all five control types. Sigma Prime classifies the residual inner-id gap as low-severity defense-in-depth (see sigp/rust-libp2p#578).

The new pin (197663d7, master tip) also includes the hickory 0.26 bump from libp2p/rust-libp2p#6395, making RUSTSEC-2026-0118 / RUSTSEC-2026-0119 unreachable in our resolved graph. Closes #989.

Lighthouse made the equivalent migration in sigp/lighthouse#8314.

Change Overview

• Drop the six libp2p* entries from [patch.crates-io] (keep quick-protobuf).
• Pin libp2p, libp2p-peer-store, and libp2p-swarm-test to upstream 197663d7.
• Builder rename in network per PR #6409: max_ihave_length(1500) → max_control_messages(1500), max_ihave_messages(32) → max_ihave_messages_heartbeat(32).
• Drop the two --ignore flags (and stale comment) from Makefile audit-CI.

Validation

• cargo check --workspace, cargo test -p network --lib (52/52), cargo clippy -p network --all-targets -- -D warnings, make cargo-fmt-check, make audit-CI — all clean.
• Zero sigp/rust-libp2p refs in Cargo.lock.

Rollback

Pure revert. No config, database, or operational impact.

Blockers / Dependencies

N/A

[diegomrsantos]

I think we should pin the new upstream rust-libp2p git dependencies in the manifests, not rely only on Cargo.lock.

The PR currently resolves to 22fb4c784fc55ad8b15d05fdc9f98d663107d4cb, and I confirmed that commit includes the upstream gossipsub hardening from libp2p/rust-libp2p#6359. The issue is that the manifest entries in Cargo.toml and anchor/network/Cargo.toml use git = ... without rev, tag, or branch. That tracks the repo default branch, so a future lockfile refresh or dependency update can silently move Anchor to newer unreleased libp2p code without a manifest diff.

For production Rust projects, the usual preference is:

• use a crates.io semver release when possible
• otherwise use a pinned git dependency, preferably a tag or exact rev

Could we either switch to the crates.io release if it contains the needed fixes, or pin all three git deps to the audited lockfile commit?

rev = "22fb4c784fc55ad8b15d05fdc9f98d663107d4cb"

That keeps the PR intent explicit: remove the SIGP fork while keeping Anchor on a reproducible upstream libp2p source.

[shane-moore]

Pushed 3f863d8 pinning all three entries to rev = "22fb4c784fc55ad8b15d05fdc9f98d663107d4cb". cargo build --workspace --locked clean.

On the crates.io option: there isn't a published version we can use today. Latest on crates.io is libp2p 0.56.0 (2025-06-27) and there's no libp2p-v0.57.0 git tag either. The 0.57.0 in the lockfile is just the in-master version = placeholder for the next release. libp2p 0.56.0 predates libp2p/rust-libp2p#6359 (merged 2026-03-31) by ~9 months, so it doesn't carry the gossipsub hardening; the recommended rev does (the PR's merge commit 5d47d9d5 is reachable from 22fb4c78).

[diegomrsantos]

On Cargo.toml:120, I think this still drops fork hardening that is not in libp2p/rust-libp2p@22fb4c784fc55ad8b15d05fdc9f98d663107d4cb.

I compared the old fork commit sigp/rust-libp2p@defcaf1a with this rev. The fork truncates incoming IWant and IDontWant message_ids before processing:

• IWant: message_ids.truncate(self.config.max_iwant_length()), default 5000
• IDontWant: message_ids.truncate(self.config.max_idontwant_messages()), default 1000

The pinned upstream rev does not have those config fields or truncation; it passes the full vectors into handle_iwant / remove_data_messages. Since Anchor only configures IHAVE limits today, a large IWANT or IDONTWANT control message can again drive unbounded work relative to the fork behavior.

I have not written a repro here, but the behavior difference is clear enough that I do not think we should drop the fork yet. Could we either pin to an upstream rev that includes the IWANT/IDONTWANT caps, or keep carrying those caps before removing the SIGP fork?

[shane-moore]

Good catch. Since I made the PR, rust-libp2p merged libp2p/rust-libp2p#6409 (2026-05-05) which adds a max_control_messages config field, applied at the codec layer (GossipsubCodec::decode) to all five control types (IHAVE, IWANT, GRAFT, PRUNE, IDONTWANT). I bumped the pin to 197663d7 (master tip, includes #6409) and set the new config to 1500 in behaviour.rs.

The semantics differ from the fork: fork was a per-entry inner cap on message_ids (5000 IWANT, 1000 IDONTWANT) in the handler match arm; #6409 is a per-RPC outer cap on the Vec<ControlIWant> (and the four others) at codec decode. So #6409 doesn't restore the exact mechanism but bounds IWANT/IDONTWANT processing on a different axis. In practice both also end up gated by max_transmit_size = 5MB at proto-decode (≈150K ids per RPC max regardless of distribution).

Note that the fork's truncate runs after the proto Vec and Vec<MessageId> are decoded, so it bounds handler iteration, not allocation. The two approaches reach comparable practical defense.

Side benefit of bumping to master tip: libp2p/rust-libp2p#6395 (hickory 0.26) is now in the resolved graph, so RUSTSEC-2026-0118 / RUSTSEC-2026-0119 are no longer reachable. Dropped the two cargo audit --ignore flags from Makefile audit-CI. Closes #989.