deps(NC-7): dig-gossip is pinned by git rev 51054a41, not a published version — invisible to every index check

[MichaelTaylor3d]

Task

dig-gossip is consumed by a git rev rather than a published version — an NC-7 violation that no index
check can see.

Pinned at rev 51054a41 in dig-node's manifests.

NC-7 (§3.6, HARD RULE): every crate under modules/crates is a real crates.io-published crate, never
git-dep-only, and consumers depend on the published version, never git = ….

Why this one survived when others were caught

A git-sourced dependency is structurally invisible to the index.crates.io freshness check that §2.4b
prescribes: the registry has nothing to report, so the dep reads as fine forever. That is the same
blind spot that let digstore-chain drift undetected until it was found blocking three epics at once, and
it is now written into CLAUDE.md §2.4b — but the rule only helps if someone looks.

Measured earlier in this ecosystem: a rev-pinned dig-gossip had drifted two minors behind its own
main — rev 51054a41 corresponded to v0.25.0 while main was at v0.30.0 with a dependency cascade
already adopted. Verify the current gap before assuming it is the same one.

And check whether dig-gossip is published at all. A prior measurement found
index.crates.io/di/g-/dig-gossip returning 404 — if that is still true, this is not a bump but a
publish-first job, and the NC-7 remedy is to publish the crate before any consumer can depend on it by
version.

Scope

1. Measure: is dig-gossip on the index? If yes, at what version, and how far is 51054a41 behind
   main?
2. If unpublished — publish it (§3.6: new crates ship the publish workflow and a real SemVer version;
   a crate is not done until it is live on crates.io and its consumers have migrated off any git dep).
3. Then repoint dig-node from the rev to the published version.

Release-first (§4.1) binds: you cannot depend on a version that is not published. If dig-gossip has
its own unpublished dependencies, walk that chain bottom-up and say what it was.

The trap to expect on the repoint

Moving off a git rev is not a no-op even when the code is identical. A rev pin and a version pin
resolve differently, and a caret-compatible sibling can silently leave an old line alive — measured here:
a cargo update -p dig-peer-selector patch bump rewrote 190 lock lines and left two dig-nat lines
and two dig-tls lines while printing success.

Verify the final state from the resolved Cargo.lock, not the caret declarations, and confirm one line
per family among crates this ecosystem declares. cargo tree -d is not a usable gate here —
chia-bls alone resolves to several lines whose roots are upstream (clvmr, chialisp) and reach no
public DIG signature. Trace a duplicate to its root and report the trace instead.

Note on dig-node's own dep state

§2.4b is currently unsatisfiable in dig-node without a full cascade — five semver-incompatible dig-*
steps (dig-nat 0.18→0.21, dig-tls 0.3→0.4, dig-peer 0.11→0.12, dig-dht 0.11.1→0.12.1,
dig-download 0.19→0.20.4), and dig-wallet is stranded on the chia 0.26 line because the chia umbrella
crate has no 0.36 release (tracked on dig-node#308). Do not attempt that cascade here — this ticket
is the git-rev violation only. Say clearly if the repoint cannot be done without it.

Evidence

• Verify any publish from the INDEX, not the workflow log — a green publish job is not a published
  crate. curl -sH 'User-Agent: dig-loop' https://index.crates.io/<a>/<b>/<crate>; the header is
  required or the response reads exactly like "not published". Use a known-bogus control.
• Read passed-counts, never ok.

Provenance

Surfaced by the review gate on DIG-Network/dig-node PR #347 (eco#2760 / #253), and independently by the
lane that fixed it — non-gating there, filed here so it is not rediscovered a third time.

[MichaelTaylor3d]

Verification sweep verdict: NOT SATISFIED as written — but SUBSUMED. Recommending close as not planned; leaving open for @MT-Dev to decide (2026-09-01)

Verified against code on origin/main (aa9ec72).

The measurement this ticket asked for, taken

Step 1 — is dig-gossip on the index? No. index.crates.io/di/g-/dig-gossip → 404 with
User-Agent: dig-loop. Controlled both ways: known-good di/g-/dig-nat → 200; bogus
di/g-/dig-zzzz-not-a-crate → 404. So the 404 is a true negative, not the header artifact the body
warns about.

The rev has moved. crates/dig-node-core/Cargo.toml:353:

dig-gossip = { git = "https://github.com/DIG-Network/dig-gossip",
               rev = "1a3391662ecce1a3cbe8b74122a52bbb1b28d3ee", ... }

51054a41 → 1a339166, and Cargo.lock:2716-2718 confirms dig-gossip 0.32.0 at that rev. So
the two-minors drift the body describes is already closed — that half of the ticket is done.

Why step 2 will never happen: publishing is the vulnerability

crates/dig-node-core/Cargo.toml:346-352 documents this as a permanent NC-7 carve-out, not a
pending publish (near-verbatim):

NC-7 exception: dig-gossip is git-pinned PERMANENTLY, not pending a publish — dig_ecosystem#2647.
It cannot be published while its native-tls [patch.crates-io] fork stands, because
cargo publish STRIPS [patch.crates-io] from the published metadata. A published dig-gossip
would therefore build against UPSTREAM native-tls, compile cleanly, and silently accept inbound
peers presenting no client certificate at all — a mutual-TLS bypass that no consumer could see
from its own manifest. Its publish.yml guard is unconditional and deliberate: do not weaken it…
dig_ecosystem#900 ("publish dig-gossip") was closed as superseded by #2647.

Cross-referenced from crates/dig-node-service/Cargo.toml:191.

So this ticket's step 2 is not merely undone — it is refused by design, and doing it would ship an
mTLS bypass. Step 3 (repoint to a published version) is unreachable by construction.

Recommended disposition

Close as not planned / superseded by dig_ecosystem#2647, mirroring exactly what already
happened to dig_ecosystem#900. Deciding a thing will never be done is a legitimate outcome, and
leaving this open implies an obligation the security rationale forbids.

Not closing it myself — this is a supersession judgement rather than a satisfied bar, so it goes to
@MT-Dev.

One real defect found while reading — a stale comment that will mislead the next lane

crates/dig-node-core/Cargo.toml:293-295 still reads "not yet published to crates.io (its publish is
guarded pending dig-peer-protocol, #681) … here v0.17.12 (rev 3e352d91)".

That names the wrong rev, the wrong version, and the wrong reason, and it directly
contradicts line 346 sixty lines below it. A lane reading the manifest top-down gets "pending a
publish" and a rev that has not been current for many releases — which is how this ticket gets
rediscovered a fourth time. Recording it as a comment rather than a new ticket (§1.3c rule 1); it is
a two-line fix for whoever next opens that manifest.

[MichaelTaylor3d]

Closing as not planned — publishing this crate is REFUSED by design, not merely undone

Verified against origin/main. The verdict comment from the sweep stands; this records the decision.

Why this is not deferred work

NC-7 says every crate publishes to crates.io and consumers depend by version. The general rule is right,
and this is a documented exception, not a gap someone forgot to close:

cargo publish strips [patch.crates-io]. dig-gossip's rustls/mTLS wiring depends on that patch, so
a published dig-gossip would build against the unpatched path and silently accept peers presenting no
client certificate. That is a §5.2 identity regression — peer_id = SHA-256(TLS SPKI DER) means an
unauthenticated peer has no identity at all — and it would ship to every consumer, not just this one.

A git rev pin is the safe shape here. Publishing is the unsafe one. Closing a ticket that asks for the
unsafe shape is the correct outcome, and §1.3c is explicit that deciding something will never be done is
a legitimate result.

Precedent and supersession

• Mirrors the same call already made on #900.
• Superseded by https://github.com/DIG-Network/dig_ecosystem/issues/2647, which owns the NC-7
  exception as a whole rather than per-consumer.
• The exception is already written into the manifest: crates/dig-node-core/Cargo.toml carries
  "NC-7 exception: same permanent git pin as the runtime dep above (dig_ecosystem#2647)".

The real defect nearby, which is NOT this ticket

crates/dig-node-core/Cargo.toml:293-295 states the wrong rev, wrong version and wrong reason for
dig-gossip, and contradicts line 346 sixty lines below. That contradiction is why this question keeps
being rediscovered as though it were open. Being fixed separately as a two-line correction — the fix is
to the comment, not to the pin.

Reopen if the [patch.crates-io] constraint is ever removed upstream; until then, publishing is the
regression.