geoprobe-target: replayed offsets still reach location_offsets (no MeasurementSlot check)

[nikw9944]

Follow-up from #4271, which closed the forgery hole in the geoprobe measurement chain. That PR added RFC-16's MeasurementSlot replay check to geoprobe-agent only. geoprobe-target — the process that writes the location_offsets table lake's public geolocation explorer aggregates — has no slot comparison at all.

What is still open

1. No replay bound on the target's ingest path

controlplane/telemetry/cmd/geoprobe-target/main.go handleOffset now drops offsets whose signature chain does not verify, which is the important half. But a signature stays valid forever, so a validly signed offset captured off the wire and replayed passes the gate unchanged and is written to ClickHouse. git grep MeasurementSlot in that file returns only display code.

This is the same attack RFC-16's MeasurementSlot field exists to stop, against the surface that feeds the public page. It is narrower than the forgery hole #4271 closed — it needs an on-path capture rather than just a UDP socket — which is why it was deliberately left out of that PR rather than growing it.

The agent's implementation is the reference to follow: offsetSlotFresh, slotReference and the maxOffsetSlotLag / maxOffsetSlotLead / maxSlotReferenceAge constants in controlplane/telemetry/cmd/geoprobe-agent/main.go. Note that geoprobe-target does not currently hold a ledger RPC client, so wiring a slot source into it is the non-trivial part of this change and should be scoped before implementing. Fail closed on an unusable slot, as the agent does.

One sizing note carried over from review of that PR: the agent sets maxSlotReferenceAge = 2 * geoprobe.SlotCacheTTL (10m) while maxOffsetSlotLead is 5m. Because a legitimate offset's slot is at most the true slot, a reference staler than the lead allowance already rejects fresh offsets while still admitting replays near the frozen slot — so the two bounds interact, and a target-side implementation should not copy the 2x multiplier without deciding it is what it wants.

2. MinCache.Update still resets best's clock on an equal RTT

controlplane/telemetry/internal/geoprobe/mincache.go:120 reads if rttNs <= c.best.rttNs and, on that branch, replaces best — which also resets its receivedAt. This is the identical defect #4271 fixed in the agent's own offsetCache.Put, where the comment now reads: "An equal-RTT offset must not replace best, because replacing also resets best's receivedAt clock — a replayed offset would otherwise hold best forever."

MinCache was not touched by that PR. In geoprobe-target the cache drives console and JSON output rather than anything persisted, so the impact is lower than it was in the agent — but the code is wrong in the same way and should match its sibling.

3. signature_valid is now a constant true

Small cleanup in the same function. Since handleOffset returns early on a failed chain, verifyError is always nil by the time the ClickHouse row is built, so the sigErrStr computation is dead and signature_valid is written true unconditionally.

Two things worth deciding rather than just deleting:

• With -verify-signatures=false (the flag defaults to true, and infra's ansible sets verify_signatures: true, so this is not the deployed configuration), nothing is verified but rows are still written with signature_valid = true. That is a mislabel, and it matters more now that the column is supposed to carry a real assertion. Recording false or a distinct "unverified" state would be more honest than asserting a check that did not run.
• Historical rows written before geoprobe: reject forged, replayed and spoofed geolocation input #4271 include signature_valid = false, and lake's geolocation handlers do not filter on the column — grep signature_valid across lake's api/ finds it only in test fixtures. So forged offsets already in mainnet-beta.location_offsets keep rendering on the public explorer even though the intake is now closed. Closing that is lake-side work, tracked separately; it is noted here so whoever picks this up knows the column's consumer does not currently read it.

Context

All of the above was found while reviewing #4271 (implemented by instance 413). None of it is a regression from that PR — items 1 and 2 predate it, and item 3 is a consequence of its fix. Read that PR's diff for the shape the fixes should follow.

[nikw9944]

Work Log — waiting_review

I'll start by reading the repo README and CLAUDE.md, then the issue and the base branch diff.

Plan written to docs/work-plan-adhoc.md.

Work plan — #4286: close the replay gap on geoprobe-target's offset ingest

Base branch: nikw9944/adhoc-413 (#4271, open, not draft, based on main).
Working branch: nikw9944/adhoc-527. Draft PR will target nikw9944/adhoc-413.

Summary

#4271 stopped forged offsets from reaching location_offsets, but a validly signed offset captured off the wire can still be replayed into geoprobe-target forever, because nothing on that path looks at MeasurementSlot. This plan covers all three items in the issue and recommends closing the replay gap without giving geoprobe-target a ledger RPC connection: instead of comparing MeasurementSlot against a live ledger slot, the target derives its freshness reference from the signed offset stream itself — it tracks the highest slot each sender has proven, and how long that high-water mark has stood still. That is cheaper, has no new external dependency, has no fail-open/fail-closed dilemma, and produces a tighter replay window than a port of the agent's check would. The two cleanups ride along in the same PR.

The open question, answered

Verified: geoprobe-target has no ledger access

grep -n "rpc\|ledger\|solana" over controlplane/telemetry/cmd/geoprobe-target/main.go returns only solana-go's pubkey formatting. No RPC client, no --ledger-rpc-url, no --env, no RPC env var. Its only inputs are the TWAMP socket, the UDP socket, and CLICKHOUSE_*. RFC-16 (line 485) describes it as example target software — a program whose whole point is that the signature chain lets it verify a measurement with no trust relationship and no chain access.

1. Should the daemon get a ledger RPC connection? — No.

The cost is not one flag. It is a solana RPC client, a slot cache and its goroutine, --env / --ledger-rpc-url plumbing, a malbeclabs/infra ansible change, and — the part that does not reverse — a standing requirement that every host running target software can reach a DZ ledger RPC endpoint. That inverts RFC-16's design for this component.

2. If yes, what on an unreachable RPC? — Moot under the recommendation, and the reason to avoid the question.

The brief is right that the agent's answer does not transfer. The agent declines to ingest and loses nothing that should have been kept. geoprobe-target records: failing closed punches holes in location_offsets for the length of an outage, and those holes are permanent — the measurement is gone, not delayed. Failing open reopens the replay gap for the same period. There is no good answer, which is itself an argument for a design that does not create the fork.

Note the coupling it would produce: the sending probe already serves a frozen cached slot indefinitely when its RPC fails (#4271 chose that deliberately — "stamping a slightly stale slot is better than the probe emitting nothing during an RPC blip"). A target-side absolute-slot check would then reject that probe's genuine offsets during the probe's outage, on top of rejecting during its own.

3. The cheaper options

Duplicate-tuple rejection within a window — insufficient. Dedup on (SenderPubkey, MeasurementSlot, Signature) stops the same datagram inside window W and nothing else. Replaying it once per W still writes a poisoned row per W forever, and the offset cache's best is re-seeded the moment its maxAge (1h) expires. To actually stop the attack the dedup memory would have to cover the retention horizon, which for ClickHouse rows is unbounded. It bounds row amplification from one capture, which the per-source-IP rate limiter already partly covers.

Bounding on the offset's own fields relative to previous offsets — insufficient and actively harmful. The cache exists to find the minimum RTT, so a replayed old minimum and a genuine new record low are indistinguishable by RTT. Any bound tight enough to catch the replay also discards real improvements, which is the one sample the geolocation constraint depends on.

Per-sender MeasurementSlot high-water mark — sufficient, and this is the recommendation. MeasurementSlot is inside the signed payload, so an attacker can replay one but cannot mint one. The highest slot a sender has ever proven is a lower bound on the true slot that the attacker cannot push forward. Two rules:

• Regression bound. Accept only while slot + maxSlotRegression >= high, where high is the highest slot proven by that sender. A replay of an older capture fails as soon as the live stream moves high past it.
• Stall bound. If high has not advanced in maxFloorStall, require a strictly higher slot. Without this, a capture taken while a probe was alive stays acceptable forever once the probe goes quiet — the same frozen-window failure geoprobe: reject forged, replayed and spoofed geolocation input #4271's maxSlotReferenceAge fixed on the agent.

Sizing: composite offsets are sent every 30s but stamped from the agent's 5-minute slot cache, so a healthy sender's slot advances at least every ~5 minutes and repeats in between. >= high (not > high) is therefore required — a strict rule would drop nine of every ten legitimate offsets.

• maxSlotRegression = 2m / 400ms = 300 slots. Absorbs a re-fetch landing on a lagging finalized replica behind a load balancer, which would otherwise silently stop that sender's ingestion.
• maxFloorStall = 30m. Deliberately more generous than the agent's 10m: the sending probe freezes its stamped slot during its own RPC outage, and dropping real measurements costs more here than admitting a replay for another twenty minutes. Rejections log at Warn so a stalled sender is visible.

Resulting replay window: roughly maxFloorStall plus the 5-minute slot-cache granularity, versus the agent's 15m lag / 5m lead. Comparable, with no ledger.

Residual gaps, stated plainly:

• Cold start. On restart, or the first offset from a never-seen sender, the high-water mark is seeded from that offset — an arbitrarily old capture is accepted once and holds for maxFloorStall. The live stream (every 30s) raises high past it quickly. Seeding new senders from a global max would close this but lets one rogue probe key stamp a future slot and lock out every other sender; not worth it.
• Suppress-and-delay. An attacker who can drop the original datagram and inject it later evades any per-sender floor. A ledger clock bounds this to 15m; the floor does not. This requires a strictly stronger position than capture-and-replay.
• This does not make the ingest path trustworthy on its own — see below.

Finding that changes how item 1 should be read

geoprobe.VerifyOffsetChain verifies only that the signature is self-consistent with the AuthorityPubkey carried in the same datagram. Unlike geoprobe-agent, geoprobe-target has no parentState and no allowlist, so it accepts an offset signed by any freshly generated keypair, with attacker-chosen Lat/Lng/RttNs, and writes it to location_offsets. An attacker who can mint offsets does not need to replay one — they stamp the current slot, which is public.

That is a larger hole than the replay gap and is out of scope here (closing it needs the onchain probe set, i.e. the same ledger dependency this plan is declining). I will file it as a separate issue and link it from the PR. It does not make the slot floor pointless — the floor is what keeps a genuine probe's signed measurement from being replayed once a consumer starts filtering on known probe pubkeys — but the PR body must not claim the ingest path is now trustworthy. I checked open issues (gh issue list --search geoprobe); nothing covers this today.

Approach

Item 1 — per-sender slot floor in geoprobe-target

New unexported type in cmd/geoprobe-target/main.go, alongside the existing rateLimiter:

type slotFloor struct {
    mu      sync.Mutex
    entries map[[32]byte]*floorEntry   // keyed by SenderPubkey
    nowFunc func() time.Time           // injectable for tests, as MinCache does
}

accept(sender [32]byte, slot uint64) (bool, string) implements the two rules and returns a reason for the log line. handleOffset gains a floor *slotFloor parameter and calls it immediately after the signature gate, before the ClickHouse write — so a rejected offset reaches neither the row nor the cache nor the console output, matching how the signature gate behaves.

Entries are swept on the existing sweepCaches ticker with the same TTL as the offset caches, so the map does not grow without bound. (MinCacheMap already has the same per-sender growth property and the same sweep; I am matching it, not fixing it.)

Item 2 — MinCache.Update equal-RTT clock reset

mincache.go:120: <= → <, carrying over the comment from the agent's offsetCache.Put. TestMinCache_EqualRTTReplacesBest encodes the old behavior. Read as intent it says "prefer the fresher of two equal measurements", which is defensible on its face and is exactly the defect: the replacement also resets receivedAt. It will be rewritten as TestMinCache_EqualRTTDoesNotReplaceBest and extended to assert the clock consequence, not just the placement.

Impact is genuinely small and the PR body will say so: in geoprobe-target the cache drives console and JSON output only, nothing persisted reads it; its other consumer, cmd/geoprobe-target-sender/main.go:84, caches that process's own RTT measurements, where there is no attacker to inject and this is a staleness bug rather than a security one. A consistency fix with its sibling.

Item 3 — signature_valid

After #4271's early return, verifyError is always nil at the row build, so sigErrStr is dead and signature_valid is unconditionally true — including with -verify-signatures=false, where nothing was checked.

Recommendation: the column should say false when no check ran, with signature_error carrying a fixed marker. signature_valid is Bool in the ClickHouse schema, so a tri-state would be a migration plus a consumer change for a configuration nobody deploys; and after #4271 no new row can be written with a failed verification, so going forward false unambiguously means "unverified" — the same instruction to a consumer as "failed": do not trust it. Populating signature_error with "signature verification disabled" keeps the two historical meanings distinguishable in the data and keeps sigErrStr from being dead code.

The deployed configuration (verify_signatures: true) writes true exactly as before, so the e2e assertions on signature_valid=true and sum(signature_valid) are unaffected.

Files to change

File	Change
controlplane/telemetry/cmd/geoprobe-target/main.go	slotFloor type + accept; constants dzSlotDuration, maxSlotRegression, maxFloorStall; wire into main, runUDPListener, handleOffset; sweep in sweepCaches; honest signature_valid / signature_error
controlplane/telemetry/cmd/geoprobe-target/main_test.go	New tests for the slot floor and the -verify-signatures=false labelling; existing handleOffset call sites updated
controlplane/telemetry/internal/geoprobe/mincache.go	<= → < in Update, with the reasoning comment
controlplane/telemetry/internal/geoprobe/mincache_test.go	TestMinCache_EqualRTTReplacesBest rewritten to assert the clock is not reset
CHANGELOG.md	Entry under the existing ## Unreleased → ### Changes → - Geolocation list
CLAUDE.md	One line under "Geolocation Architecture": geoprobe-target holds no ledger connection by design and derives offset freshness from the signed stream — an invariant a future change could silently break
rfcs/rfc16-geolocation-verification.md	One line on the Replay Attacks row of the security table (line 675). Only if the design is approved as written

No README change. No changelog.d/ — this repo does not use one; #4271 edited CHANGELOG.md directly and the entry goes under the existing ## Unreleased.

Risks & considerations

• Ingestion outage risk is the main one. Any acceptance rule can drop real measurements. Two ways this one can: a sender whose stamped slot regresses by more than maxSlotRegression (lagging finalized replica), and a sender whose slot freezes for more than maxFloorStall (its own RPC outage). Both log at Warn with both slot values. geoprobe-target has no prometheus metrics today; adding a metrics server for this would be a larger change than the fix, so logs are the signal. A counter is a reasonable follow-up if the reviewer wants one.
• Constant sizing is the reviewable judgment call. maxFloorStall = 30m is a product tradeoff, not a derived number, and I would rather be argued down than silently tight. The issue's own note about not copying the agent's 2x multiplier applies here in the opposite direction.
• Cold-start exposure as described: one accepted replay per restart per sender, held for at most maxFloorStall.
• Backwards compatibility: no wire format change, no schema change, no new flags, no malbeclabs/infra config change. Rows written before this keep their meaning.
• Base branch: nikw9944/adhoc-413 is behind main and conflicts on CHANGELOG.md by design. I will not merge main into it and will not retarget. If geoprobe: reject forged, replayed and spoofed geolocation input #4271 gains commits I will merge them in; no rebase, no force-push once pushed. If it merges while I work, I will say so and leave the retarget to the reviewer.

Testing strategy

Local build and test work in this container using GOTOOLCHAIN=local GOPROXY=direct — the default proxy's zip redirects to storage.googleapis.com, which is blocked, but direct fetches from github.com, which is allowed. Verified: go build ./controlplane/telemetry/... succeeds, and go test passes on internal/geoprobe, cmd/geoprobe-agent and cmd/geoprobe-target. The predicted klauspost/compress / pierrec/lz4/v4 blocker does not apply.

Every behavior change gets a test that fails without the fix, verified by reverting the production change and watching it fail, then restoring — not inferred. Following TestRunOffsetListener_RejectsOffsetOutsideSlotWindow and TestHandleOffset_DropsUnsignedOffset, each test asserts the defect's signature and carries a positive control proving the rejection came from the new check.

1. TestHandleOffset_RejectsReplayedOffset — a signed offset establishes the floor; a second signed offset maxSlotRegression + 1 behind reaches neither ClickHouse nor the cache. Positive control: a fresh-slot offset over the same path is accepted.
2. TestSlotFloor_AcceptsRepeatedSlotWhileFresh — the same slot repeated inside maxFloorStall is accepted (the case a strict > rule would break, and what makes the rule deployable).
3. TestSlotFloor_RejectsStalledFloor — with the injected clock past maxFloorStall, an offset at the frozen slot is rejected; a higher slot is accepted.
4. TestSlotFloor_IsPerSender — a second sender's low slot is not judged against the first's floor.
5. TestMinCache_EqualRTTDoesNotReplaceBest — equal-RTT samples across more than maxAge do not keep best alive past its original expiry. Positive control: a strictly lower sample does extend it. Fails on the current <=.
6. TestHandleOffset_UnverifiedRowIsNotLabelledValid — with verifySignatures=false, the buffered row carries signature_valid=false and the marker signature_error.

Full gates: make build, make lint, make test — reported honestly, with anything I could not run named rather than glossed. make e2e-test RUN=TestE2E_Geoprobe needs Docker and cEOS, which this container does not have; I will state that plainly rather than treating unit tests as sufficient, and call out that this change alters ingest acceptance so an e2e run before merge is worth a reviewer's time. I will not watch CI after pushing.

Estimated scope

~75 new production lines (≈60 slot floor and wiring, ≈8 signature_valid, ≈4 mincache), plus ~190 test lines and ~15 lines of docs/changelog. Well inside the repo's 500-line guidance; one PR.

Open Questions

1. Do you accept the recommendation to close the replay gap without adding a ledger RPC connection to geoprobe-target — a per-sender MeasurementSlot high-water mark with a stall bound, instead of a port of the agent's absolute-slot check? If you would rather have the ledger dependency, say so and I will scope the PR to items 2 and 3 only and leave item 1 for a change that includes the malbeclabs/infra work.
2. Is maxFloorStall = 30m the right tradeoff? It is how long a sender may keep repeating the same MeasurementSlot before the target stops believing it is live. Shorter closes the replay window faster; longer avoids dropping genuine measurements while the sending probe rides out its own ledger-RPC outage on a frozen cached slot. 10m would match the agent's maxSlotReferenceAge but would drop real data during any probe-side RPC outage longer than that.
3. Do you agree signature_valid should be written false (with signature_error = "signature verification disabled") when -verify-signatures=false, rather than keeping the constant true or adding a tri-state column? A tri-state means a ClickHouse migration and a lake change for a configuration that is not deployed.
4. Should I file the separate issue for the missing authority allowlist on geoprobe-target — that VerifyOffsetChain only checks self-consistency, so any freshly generated keypair can write attacker-chosen coordinates into location_offsets? I plan to file it and link it from the PR without acting on it.

---

Next step: answer question 1 (the ledger-versus-stream design call). It is the only one that changes the size of the PR — the other three are refinements I can carry either way.

Fences: v4 (3 active)

STATUS: COMPLETE

--- Result: success | Session cost: $3.2989 | Turns: 38 | Tokens: 60 in / 37269 out | 2026-09-09 22:39:29 UTC ---

[nikw9944]

Approved Work Plan (Revision 0)

Approved Work Plan (Revision 0)

Work plan — #4286: close the replay gap on geoprobe-target's offset ingest

Base branch: nikw9944/adhoc-413 (#4271, open, not draft, based on main).
Working branch: nikw9944/adhoc-527. Draft PR will target nikw9944/adhoc-413.

Summary

#4271 stopped forged offsets from reaching location_offsets, but a validly signed
offset captured off the wire can still be replayed into geoprobe-target forever, because nothing on
that path looks at MeasurementSlot. This plan covers all three items in the issue and recommends
closing the replay gap without giving geoprobe-target a ledger RPC connection: instead of
comparing MeasurementSlot against a live ledger slot, the target derives its freshness reference
from the signed offset stream itself — it tracks the highest slot each sender has proven, and how
long that high-water mark has stood still. That is cheaper, has no new external dependency, has no
fail-open/fail-closed dilemma, and produces a tighter replay window than a port of the agent's
check would. The two cleanups (MinCache.Update's equal-RTT clock reset, and the now-constant
signature_valid) ride along in the same PR.

The open question, answered

Verified: geoprobe-target has no ledger access

grep -n "rpc\|ledger\|solana" controlplane/telemetry/cmd/geoprobe-target/main.go returns only
solana-go's pubkey formatting. There is no RPC client, no --ledger-rpc-url, no --env, and no
RPC environment variable. Its only inputs are the TWAMP socket, the UDP socket, and
CLICKHOUSE_* env vars. RFC-16 (line 485) describes it as example target software — a program
whose whole point is that the signature chain lets it verify a measurement with no trust
relationship and no chain access.

1. Should the daemon get a ledger RPC connection? — No.

The cost is not one flag. It is a solana RPC client, a slot cache and its goroutine, --env /
--ledger-rpc-url plumbing, a malbeclabs/infra ansible change, and — the part that does not
reverse — a standing requirement that every host running target software can reach a DZ ledger RPC
endpoint. That inverts RFC-16's design for this component.

2. If yes, what on an unreachable RPC? — Moot under the recommendation, and the reason to avoid the question.

The brief is right that the agent's answer does not transfer. The agent declines to ingest, and
loses nothing that should have been kept. geoprobe-target records: failing closed there punches
holes in location_offsets for the length of an outage, and those holes are permanent — the
measurement is gone, not delayed. Failing open reopens the replay gap for the same period. There is
no good answer, which is itself an argument for a design that does not create the fork.

Note the coupling this would produce: the sending probe already serves a frozen cached slot
indefinitely when its RPC fails (#4271 chose that deliberately — "stamping a
slightly stale slot is better than the probe emitting nothing during an RPC blip"). A target-side
absolute-slot check would then reject that probe's genuine offsets during the probe's outage, on
top of rejecting during its own.

3. The cheaper options

Duplicate-tuple rejection within a window — insufficient. Dedup on
(SenderPubkey, MeasurementSlot, Signature) stops the same datagram inside window W and nothing
else. Replaying it once per W still writes a poisoned row per W forever, and the offset cache's
best is re-seeded the moment its maxAge (1h) expires. To actually stop the attack the dedup
memory would have to cover the retention horizon, which for ClickHouse rows is unbounded. It also
costs an unbounded seen-set. It does bound row amplification from one capture, but that is
already partly covered by the per-source-IP rate limiter.

Bounding on the offset's own fields relative to previous offsets from the same sender —
insufficient and actively harmful. The cache exists to find the minimum RTT, so a replayed old
minimum and a genuine new record low are indistinguishable by RTT. Any bound tight enough to catch
the replay also discards real improvements, which is the one sample the geolocation constraint
depends on.

Per-sender MeasurementSlot high-water mark — sufficient, and this is the recommendation.
MeasurementSlot is inside the signed payload, so an attacker can replay one but cannot mint one.
The highest slot a sender has ever proven is therefore a lower bound on the true slot that the
attacker cannot push forward. Two rules:

• Regression bound. Accept a sender's offset only while slot + maxSlotRegression >= high,
  where high is the highest slot proven by that sender. A replay of an older capture fails this
  as soon as the live stream moves high past it.
• Stall bound. If high has not advanced in maxFloorStall, stop accepting at high —
  require a strictly higher slot. Without this, a capture taken while a probe was alive stays
  acceptable forever once the probe goes quiet, which is the same "frozen window" failure
  geoprobe: reject forged, replayed and spoofed geolocation input #4271's maxSlotReferenceAge fixed on the agent.

Sizing: composite offsets are sent every 30s but stamped from the agent's 5-minute slot cache, so a
healthy sender's slot advances at least every ~5 minutes and repeats in between. >= high (not
> high) is therefore required — a strict rule would drop nine of every ten legitimate offsets.

• maxSlotRegression = 2m / 400ms = 300 slots. Absorbs a re-fetch landing on a lagging finalized
  replica behind a load balancer, which would otherwise silently stop that sender's ingestion.
• maxFloorStall = 30m. Deliberately more generous than the agent's 10m: the sending probe freezes
  its stamped slot during its own RPC outage, and dropping real measurements costs more here than
  admitting a replay for another twenty minutes. Rejections log at Warn so a stalled sender is
  visible.

Resulting replay window: roughly maxFloorStall plus the 5-minute slot-cache granularity, versus
the agent's 15m lag / 5m lead. Comparable, with no ledger.

Residual gaps, stated plainly:

• Cold start. On process restart, or the first offset from a never-seen sender, the high-water
  mark is seeded from that offset — so an arbitrarily old capture is accepted once and holds for
  maxFloorStall. The live stream (every 30s) raises high past it quickly. Seeding new senders
  from a global max across senders would close this, but lets one rogue probe key stamp a future
  slot and lock out every other sender; not worth it.
• Suppress-and-delay. An attacker who can drop the original datagram and inject it later evades
  any per-sender floor. A ledger clock bounds this to 15m; the floor does not. This requires a
  strictly stronger position than capture-and-replay.
• This does not make the ingest path trustworthy on its own — see the finding below.

Finding that changes how item 1 should be read

geoprobe.VerifyOffsetChain verifies only that the signature is self-consistent with the
AuthorityPubkey carried in the same datagram. Unlike geoprobe-agent, geoprobe-target has no
parentState and no allowlist, so it accepts an offset signed by any freshly generated keypair,
with attacker-chosen Lat/Lng/RttNs, and writes it to location_offsets. An attacker who can
mint offsets does not need to replay one at all — they stamp the current slot, which is public.

That is a larger hole than the replay gap and it is out of scope here (closing it needs the
onchain probe set, i.e. the same ledger dependency this plan is declining, and it is a different
change). I will file it as a separate issue and link it from the PR. It does not make the slot floor
pointless — the floor is what keeps a genuine probe's signed measurement from being replayed once
a consumer starts filtering on known probe pubkeys — but the PR body must not claim the ingest path
is now trustworthy.

I checked open issues (gh issue list --search geoprobe); nothing covers this today.

Approach

Item 1 — per-sender slot floor in geoprobe-target

New unexported type in cmd/geoprobe-target/main.go, alongside the existing rateLimiter:

type slotFloor struct {
    mu      sync.Mutex
    entries map[[32]byte]*floorEntry   // keyed by SenderPubkey
    nowFunc func() time.Time           // injectable for tests, as MinCache does
}

accept(sender [32]byte, slot uint64) (bool, string) implements the two rules and returns a reason
for the log line. handleOffset gains a floor *slotFloor parameter and calls it immediately after
the signature gate, before the ClickHouse write — so a rejected offset reaches neither the row nor
the cache nor the console output, matching how the signature gate behaves.

Entries are swept on the existing sweepCaches ticker with the same TTL as the offset caches, so
the map does not grow without bound. (MinCacheMap already has the same per-sender growth property
and the same sweep; I am matching it, not fixing it.)

Item 2 — MinCache.Update equal-RTT clock reset

mincache.go:120: <= → <, carrying over the comment from the agent's offsetCache.Put.
TestMinCache_EqualRTTReplacesBest encodes the old behavior. Read as intent, it says "prefer the
fresher of two equal measurements", which is defensible on its face and is exactly the defect: the
replacement also resets receivedAt. It will be rewritten as TestMinCache_EqualRTTDoesNotReplaceBest
and extended to assert the clock consequence, not just the placement.

Impact is genuinely small and the PR body will say so: in geoprobe-target the cache drives console
and JSON output only, nothing persisted reads it; its other consumer,
cmd/geoprobe-target-sender/main.go:84, caches that process's own RTT measurements, where there is
no attacker to inject and this is a staleness bug rather than a security one. This is a
consistency fix with its sibling.

Item 3 — signature_valid

After #4271's early return, verifyError is always nil at the row build, so
sigErrStr is dead and signature_valid is unconditionally true — including with
-verify-signatures=false, where nothing was checked.

Recommendation: the column should say false when no check ran, with signature_error carrying
a fixed marker. Reasons: signature_valid is Bool in the ClickHouse schema, so a tri-state
would be a migration plus a consumer change for a configuration nobody deploys; and after
#4271 no new row can be written with a failed verification, so going forward
false unambiguously means "unverified", which is the same instruction to a consumer as "failed" —
do not trust it. Populating signature_error with "signature verification disabled" keeps the
two historical meanings distinguishable in the data and keeps sigErrStr from being dead code.

The deployed configuration (verify_signatures: true) writes true exactly as before, so the e2e
assertions on signature_valid=true and sum(signature_valid) are unaffected.

Files to change

File	Change
controlplane/telemetry/cmd/geoprobe-target/main.go	slotFloor type + accept; constants dzSlotDuration, maxSlotRegression, maxFloorStall; wire into main, runUDPListener, handleOffset; sweep in sweepCaches; honest signature_valid / signature_error
controlplane/telemetry/cmd/geoprobe-target/main_test.go	New tests for the slot floor and for the -verify-signatures=false labelling; existing handleOffset call sites updated for the new parameter
controlplane/telemetry/internal/geoprobe/mincache.go	<= → < in Update, with the reasoning comment
controlplane/telemetry/internal/geoprobe/mincache_test.go	TestMinCache_EqualRTTReplacesBest rewritten to assert the clock is not reset
CHANGELOG.md	Entry under the existing ## Unreleased → ### Changes → - Geolocation list
CLAUDE.md	One line under "Geolocation Architecture": geoprobe-target holds no ledger connection by design and derives offset freshness from the signed stream. This is an invariant a future change could silently break
rfcs/rfc16-geolocation-verification.md	One line on the Replay Attacks row of the security table (line 675) noting the target's mitigation is stream-derived, not ledger-derived. Only if the design is approved as written

No README change. No changelog.d/ — this repo does not use one; #4271 edited
CHANGELOG.md directly and the entry goes under the existing ## Unreleased.

Risks & considerations

• Ingestion outage risk is the main one. Any acceptance rule can drop real measurements. The
  two ways this rule can: a sender whose stamped slot regresses by more than maxSlotRegression
  (lagging finalized replica), and a sender whose slot freezes for more than maxFloorStall
  (its own RPC outage). Both log at Warn with both slot values so the cause is readable in logs.
  geoprobe-target has no prometheus metrics today; adding a metrics server for this would be a
  larger change than the fix, so logs are the signal. If the reviewer wants a counter, that is a
  reasonable follow-up.
• Constant sizing is the reviewable judgment call. maxFloorStall = 30m is a product tradeoff,
  not a derived number, and I would rather be argued down than silently tight. The issue's own note
  about not copying the agent's 2x multiplier applies here too, in the opposite direction.
• Cold-start exposure as described above: one accepted replay per restart per sender, held for
  at most maxFloorStall.
• Backwards compatibility: no wire format change, no schema change, no new flags, no config
  change in malbeclabs/infra. Rows written before this keep their meaning.
• Base branch: nikw9944/adhoc-413 is behind main and conflicts on CHANGELOG.md by design.
  I will not merge main into it and will not retarget. If geoprobe: reject forged, replayed and spoofed geolocation input #4271 gains
  commits I will merge them in; I will not rebase or force-push once pushed. If it merges while I
  work, I will say so and leave the retarget to the reviewer.

Testing strategy

Local build and test work in this container using GOTOOLCHAIN=local GOPROXY=direct — the default
proxy's zip redirects to storage.googleapis.com, which is blocked, but direct fetches from
github.com, which is allowed. Verified: go build ./controlplane/telemetry/... succeeds, and
go test passes on internal/geoprobe, cmd/geoprobe-agent and cmd/geoprobe-target. So the
predicted klauspost/compress / pierrec/lz4/v4 blocker does not apply.

Every behavior change gets a test that fails without the fix, verified by reverting the production
change and watching it fail, then restoring — not inferred. Following
TestRunOffsetListener_RejectsOffsetOutsideSlotWindow and TestHandleOffset_DropsUnsignedOffset,
each test asserts the defect's signature and carries a positive control proving the rejection came
from the new check.

1. TestHandleOffset_RejectsReplayedOffset — a signed offset establishes the floor; a second signed
   offset with a slot maxSlotRegression + 1 behind it reaches neither ClickHouse nor the cache.
   Positive control: a fresh-slot offset over the same path is accepted.
2. TestSlotFloor_AcceptsRepeatedSlotWhileFresh — the same slot repeated inside maxFloorStall is
   accepted (this is the case a strict > rule would break, and it is what makes the rule
   deployable).
3. TestSlotFloor_RejectsStalledFloor — with the injected clock advanced past maxFloorStall, an
   offset at the frozen slot is rejected; one at a higher slot is accepted.
4. TestSlotFloor_IsPerSender — a second sender's low slot is not judged against the first's floor.
5. TestMinCache_EqualRTTDoesNotReplaceBest — feeding equal-RTT samples across more than maxAge
   does not keep best alive past its original expiry. Positive control: a strictly lower sample
   does extend it. Fails on the current <=.
6. TestHandleOffset_UnverifiedRowIsNotLabelledValid — with verifySignatures=false, the buffered
   row carries signature_valid=false and the marker signature_error.

Full gates: make build, make lint, make test — reported honestly, with anything I could not
run named rather than glossed.

make e2e-test RUN=TestE2E_Geoprobe needs Docker and cEOS, which this container does not have. I
will state that plainly rather than treating unit tests as sufficient, and will call out the
live-environment risk: this change alters ingest acceptance, so an e2e run before merge is worth a
reviewer's time. I will not watch CI after pushing.

Estimated scope

~75 new production lines (≈60 slot floor and wiring, ≈8 signature_valid, ≈4 mincache), plus
~190 test lines and ~15 lines of docs/changelog. Well inside the repo's 500-line guidance; one PR.

Open Questions

1. Do you accept the recommendation to close the replay gap without adding a ledger RPC
   connection to geoprobe-target — using a per-sender MeasurementSlot high-water mark with a stall
   bound instead of a port of the agent's absolute-slot check? If you would rather have the ledger
   dependency, say so and I will scope the PR to items 2 and 3 only and leave item 1 for a change
   that includes the malbeclabs/infra work.
2. Is maxFloorStall = 30m the right tradeoff? It is how long a sender may keep repeating the same
   MeasurementSlot before the target stops believing it is live. Shorter closes the replay window
   faster; longer avoids dropping genuine measurements while the sending probe rides out its own
   ledger-RPC outage on a frozen cached slot. 10m would match the agent's maxSlotReferenceAge but
   would drop real data during any probe-side RPC outage longer than that.
3. Do you agree signature_valid should be written false (with signature_error = "signature
   verification disabled") when -verify-signatures=false, rather than keeping the constant true
   or adding a tri-state column? A tri-state means a ClickHouse migration and a lake change for a
   configuration that is not deployed.
4. Should I file the separate issue for the missing authority allowlist on geoprobe-target — that
   VerifyOffsetChain only checks self-consistency, so any freshly generated keypair can write
   attacker-chosen coordinates into location_offsets? I plan to file it and link it from the PR
   without acting on it.

[nikw9944]

Work Plan (Revision 1)

Work Plan (Revision 1)

Work plan — #4286: close the replay gap on geoprobe-target's offset ingest

Base branch: nikw9944/adhoc-413 (#4271, open, not draft, based on main).
Working branch: nikw9944/adhoc-527. Draft PR will target nikw9944/adhoc-413.

Summary

#4271 stopped forged offsets from reaching location_offsets, but a validly signed
offset captured off the wire can still be replayed into geoprobe-target forever, because nothing on
that path looks at MeasurementSlot. This plan covers all three items in the issue and recommends
closing the replay gap without giving geoprobe-target a ledger RPC connection: instead of
comparing MeasurementSlot against a live ledger slot, the target derives its freshness reference
from the signed offset stream itself — it tracks the highest slot each sender has proven, and how
long that high-water mark has stood still. That is cheaper, has no new external dependency, has no
fail-open/fail-closed dilemma, and produces a tighter replay window than a port of the agent's
check would. The two cleanups (MinCache.Update's equal-RTT clock reset, and the now-constant
signature_valid) ride along in the same PR.

The open question, answered

Verified: geoprobe-target has no ledger access

grep -n "rpc\|ledger\|solana" controlplane/telemetry/cmd/geoprobe-target/main.go returns only
solana-go's pubkey formatting. There is no RPC client, no --ledger-rpc-url, no --env, and no
RPC environment variable. Its only inputs are the TWAMP socket, the UDP socket, and
CLICKHOUSE_* env vars. RFC-16 (line 485) describes it as example target software — a program
whose whole point is that the signature chain lets it verify a measurement with no trust
relationship and no chain access.

1. Should the daemon get a ledger RPC connection? — No.

The cost is not one flag. It is a solana RPC client, a slot cache and its goroutine, --env /
--ledger-rpc-url plumbing, a malbeclabs/infra ansible change, and — the part that does not
reverse — a standing requirement that every host running target software can reach a DZ ledger RPC
endpoint. That inverts RFC-16's design for this component.

2. If yes, what on an unreachable RPC? — Moot under the recommendation, and the reason to avoid the question.

The brief is right that the agent's answer does not transfer. The agent declines to ingest, and
loses nothing that should have been kept. geoprobe-target records: failing closed there punches
holes in location_offsets for the length of an outage, and those holes are permanent — the
measurement is gone, not delayed. Failing open reopens the replay gap for the same period. There is
no good answer, which is itself an argument for a design that does not create the fork.

Note the coupling this would produce: the sending probe already serves a frozen cached slot
indefinitely when its RPC fails (#4271 chose that deliberately — "stamping a
slightly stale slot is better than the probe emitting nothing during an RPC blip"). A target-side
absolute-slot check would then reject that probe's genuine offsets during the probe's outage, on
top of rejecting during its own.

3. The cheaper options

Duplicate-tuple rejection within a window — insufficient. Dedup on
(SenderPubkey, MeasurementSlot, Signature) stops the same datagram inside window W and nothing
else. Replaying it once per W still writes a poisoned row per W forever, and the offset cache's
best is re-seeded the moment its maxAge (1h) expires. To actually stop the attack the dedup
memory would have to cover the retention horizon, which for ClickHouse rows is unbounded. It also
costs an unbounded seen-set. It does bound row amplification from one capture, but that is
already partly covered by the per-source-IP rate limiter.

Bounding on the offset's own fields relative to previous offsets from the same sender —
insufficient and actively harmful. The cache exists to find the minimum RTT, so a replayed old
minimum and a genuine new record low are indistinguishable by RTT. Any bound tight enough to catch
the replay also discards real improvements, which is the one sample the geolocation constraint
depends on.

Per-sender MeasurementSlot high-water mark — sufficient, and this is the recommendation.
MeasurementSlot is inside the signed payload, so an attacker can replay one but cannot mint one.
The highest slot a sender has ever proven is therefore a lower bound on the true slot that the
attacker cannot push forward. Two rules:

• Regression bound. Accept a sender's offset only while slot + maxSlotRegression >= high,
  where high is the highest slot proven by that sender. A replay of an older capture fails this
  as soon as the live stream moves high past it.
• Stall bound. If high has not advanced in maxFloorStall, stop accepting at high —
  require a strictly higher slot. Without this, a capture taken while a probe was alive stays
  acceptable forever once the probe goes quiet, which is the same "frozen window" failure
  geoprobe: reject forged, replayed and spoofed geolocation input #4271's maxSlotReferenceAge fixed on the agent.

Sizing: composite offsets are sent every 30s but stamped from the agent's 5-minute slot cache, so a
healthy sender's slot advances at least every ~5 minutes and repeats in between. >= high (not
> high) is therefore required — a strict rule would drop nine of every ten legitimate offsets.

• maxSlotRegression = 2m / 400ms = 300 slots. Absorbs a re-fetch landing on a lagging finalized
  replica behind a load balancer, which would otherwise silently stop that sender's ingestion.
• maxFloorStall = 30m. Deliberately more generous than the agent's 10m: the sending probe freezes
  its stamped slot during its own RPC outage, and dropping real measurements costs more here than
  admitting a replay for another twenty minutes. Rejections log at Warn so a stalled sender is
  visible.

Resulting replay window: roughly maxFloorStall plus the 5-minute slot-cache granularity, versus
the agent's 15m lag / 5m lead. Comparable, with no ledger.

Residual gaps, stated plainly:

• Cold start. On process restart, or the first offset from a never-seen sender, the high-water
  mark is seeded from that offset — so an arbitrarily old capture is accepted once and holds for
  maxFloorStall. The live stream (every 30s) raises high past it quickly. Seeding new senders
  from a global max across senders would close this, but lets one rogue probe key stamp a future
  slot and lock out every other sender; not worth it.
• Suppress-and-delay. An attacker who can drop the original datagram and inject it later evades
  any per-sender floor. A ledger clock bounds this to 15m; the floor does not. This requires a
  strictly stronger position than capture-and-replay.
• This does not make the ingest path trustworthy on its own — see the finding below.

Finding that changes how item 1 should be read

geoprobe.VerifyOffsetChain verifies only that the signature is self-consistent with the
AuthorityPubkey carried in the same datagram. Unlike geoprobe-agent, geoprobe-target has no
parentState and no allowlist, so it accepts an offset signed by any freshly generated keypair,
with attacker-chosen Lat/Lng/RttNs, and writes it to location_offsets. An attacker who can
mint offsets does not need to replay one at all — they stamp the current slot, which is public.

That is a larger hole than the replay gap and it is out of scope here (closing it needs the
onchain probe set, i.e. the same ledger dependency this plan is declining, and it is a different
change). I will file it as a separate issue and link it from the PR. It does not make the slot floor
pointless — the floor is what keeps a genuine probe's signed measurement from being replayed once
a consumer starts filtering on known probe pubkeys — but the PR body must not claim the ingest path
is now trustworthy.

I checked open issues (gh issue list --search geoprobe); nothing covers this today.

Approach

Item 1 — per-sender slot floor in geoprobe-target

New unexported type in cmd/geoprobe-target/main.go, alongside the existing rateLimiter:

type slotFloor struct {
    mu      sync.Mutex
    entries map[[32]byte]*floorEntry   // keyed by SenderPubkey
    nowFunc func() time.Time           // injectable for tests, as MinCache does
}

accept(sender [32]byte, slot uint64) (bool, string) implements the two rules and returns a reason
for the log line. handleOffset gains a floor *slotFloor parameter and calls it immediately after
the signature gate, before the ClickHouse write — so a rejected offset reaches neither the row nor
the cache nor the console output, matching how the signature gate behaves.

Entries are swept on the existing sweepCaches ticker with the same TTL as the offset caches, so
the map does not grow without bound. (MinCacheMap already has the same per-sender growth property
and the same sweep; I am matching it, not fixing it.)

Item 2 — MinCache.Update equal-RTT clock reset

mincache.go:120: <= → <, carrying over the comment from the agent's offsetCache.Put.
TestMinCache_EqualRTTReplacesBest encodes the old behavior. Read as intent, it says "prefer the
fresher of two equal measurements", which is defensible on its face and is exactly the defect: the
replacement also resets receivedAt. It will be rewritten as TestMinCache_EqualRTTDoesNotReplaceBest
and extended to assert the clock consequence, not just the placement.

Impact is genuinely small and the PR body will say so: in geoprobe-target the cache drives console
and JSON output only, nothing persisted reads it; its other consumer,
cmd/geoprobe-target-sender/main.go:84, caches that process's own RTT measurements, where there is
no attacker to inject and this is a staleness bug rather than a security one. This is a
consistency fix with its sibling.

Item 3 — signature_valid

After #4271's early return, verifyError is always nil at the row build, so
sigErrStr is dead and signature_valid is unconditionally true — including with
-verify-signatures=false, where nothing was checked.

Recommendation: the column should say false when no check ran, with signature_error carrying
a fixed marker. Reasons: signature_valid is Bool in the ClickHouse schema, so a tri-state
would be a migration plus a consumer change for a configuration nobody deploys; and after
#4271 no new row can be written with a failed verification, so going forward
false unambiguously means "unverified", which is the same instruction to a consumer as "failed" —
do not trust it. Populating signature_error with "signature verification disabled" keeps the
two historical meanings distinguishable in the data and keeps sigErrStr from being dead code.

The deployed configuration (verify_signatures: true) writes true exactly as before, so the e2e
assertions on signature_valid=true and sum(signature_valid) are unaffected.

Files to change

File	Change
controlplane/telemetry/cmd/geoprobe-target/main.go	slotFloor type + accept; constants dzSlotDuration, maxSlotRegression, maxFloorStall; wire into main, runUDPListener, handleOffset; sweep in sweepCaches; honest signature_valid / signature_error
controlplane/telemetry/cmd/geoprobe-target/main_test.go	New tests for the slot floor and for the -verify-signatures=false labelling; existing handleOffset call sites updated for the new parameter
controlplane/telemetry/internal/geoprobe/mincache.go	<= → < in Update, with the reasoning comment
controlplane/telemetry/internal/geoprobe/mincache_test.go	TestMinCache_EqualRTTReplacesBest rewritten to assert the clock is not reset
CHANGELOG.md	Entry under the existing ## Unreleased → ### Changes → - Geolocation list
CLAUDE.md	One line under "Geolocation Architecture": geoprobe-target holds no ledger connection by design and derives offset freshness from the signed stream. This is an invariant a future change could silently break
rfcs/rfc16-geolocation-verification.md	One line on the Replay Attacks row of the security table (line 675) noting the target's mitigation is stream-derived, not ledger-derived. Only if the design is approved as written

No README change. No changelog.d/ — this repo does not use one; #4271 edited
CHANGELOG.md directly and the entry goes under the existing ## Unreleased.

Risks & considerations

• Ingestion outage risk is the main one. Any acceptance rule can drop real measurements. The
  two ways this rule can: a sender whose stamped slot regresses by more than maxSlotRegression
  (lagging finalized replica), and a sender whose slot freezes for more than maxFloorStall
  (its own RPC outage). Both log at Warn with both slot values so the cause is readable in logs.
  geoprobe-target has no prometheus metrics today; adding a metrics server for this would be a
  larger change than the fix, so logs are the signal. If the reviewer wants a counter, that is a
  reasonable follow-up.
• Constant sizing is the reviewable judgment call. maxFloorStall = 30m is a product tradeoff,
  not a derived number, and I would rather be argued down than silently tight. The issue's own note
  about not copying the agent's 2x multiplier applies here too, in the opposite direction.
• Cold-start exposure as described above: one accepted replay per restart per sender, held for
  at most maxFloorStall.
• Backwards compatibility: no wire format change, no schema change, no new flags, no config
  change in malbeclabs/infra. Rows written before this keep their meaning.
• Base branch: nikw9944/adhoc-413 is behind main and conflicts on CHANGELOG.md by design.
  I will not merge main into it and will not retarget. If geoprobe: reject forged, replayed and spoofed geolocation input #4271 gains
  commits I will merge them in; I will not rebase or force-push once pushed. If it merges while I
  work, I will say so and leave the retarget to the reviewer.

Testing strategy

Local build and test work in this container using GOTOOLCHAIN=local GOPROXY=direct — the default
proxy's zip redirects to storage.googleapis.com, which is blocked, but direct fetches from
github.com, which is allowed. Verified: go build ./controlplane/telemetry/... succeeds, and
go test passes on internal/geoprobe, cmd/geoprobe-agent and cmd/geoprobe-target. So the
predicted klauspost/compress / pierrec/lz4/v4 blocker does not apply.

Every behavior change gets a test that fails without the fix, verified by reverting the production
change and watching it fail, then restoring — not inferred. Following
TestRunOffsetListener_RejectsOffsetOutsideSlotWindow and TestHandleOffset_DropsUnsignedOffset,
each test asserts the defect's signature and carries a positive control proving the rejection came
from the new check.

1. TestHandleOffset_RejectsReplayedOffset — a signed offset establishes the floor; a second signed
   offset with a slot maxSlotRegression + 1 behind it reaches neither ClickHouse nor the cache.
   Positive control: a fresh-slot offset over the same path is accepted.
2. TestSlotFloor_AcceptsRepeatedSlotWhileFresh — the same slot repeated inside maxFloorStall is
   accepted (this is the case a strict > rule would break, and it is what makes the rule
   deployable).
3. TestSlotFloor_RejectsStalledFloor — with the injected clock advanced past maxFloorStall, an
   offset at the frozen slot is rejected; one at a higher slot is accepted.
4. TestSlotFloor_IsPerSender — a second sender's low slot is not judged against the first's floor.
5. TestMinCache_EqualRTTDoesNotReplaceBest — feeding equal-RTT samples across more than maxAge
   does not keep best alive past its original expiry. Positive control: a strictly lower sample
   does extend it. Fails on the current <=.
6. TestHandleOffset_UnverifiedRowIsNotLabelledValid — with verifySignatures=false, the buffered
   row carries signature_valid=false and the marker signature_error.

Full gates: make build, make lint, make test — reported honestly, with anything I could not
run named rather than glossed.

make e2e-test RUN=TestE2E_Geoprobe needs Docker and cEOS, which this container does not have. I
will state that plainly rather than treating unit tests as sufficient, and will call out the
live-environment risk: this change alters ingest acceptance, so an e2e run before merge is worth a
reviewer's time. I will not watch CI after pushing.

Estimated scope

~75 new production lines (≈60 slot floor and wiring, ≈8 signature_valid, ≈4 mincache), plus
~190 test lines and ~15 lines of docs/changelog. Well inside the repo's 500-line guidance; one PR.

Open Questions

1. Do you accept the recommendation to close the replay gap without adding a ledger RPC
   connection to geoprobe-target — using a per-sender MeasurementSlot high-water mark with a stall
   bound instead of a port of the agent's absolute-slot check? If you would rather have the ledger
   dependency, say so and I will scope the PR to items 2 and 3 only and leave item 1 for a change
   that includes the malbeclabs/infra work.
2. Is maxFloorStall = 30m the right tradeoff? It is how long a sender may keep repeating the same
   MeasurementSlot before the target stops believing it is live. Shorter closes the replay window
   faster; longer avoids dropping genuine measurements while the sending probe rides out its own
   ledger-RPC outage on a frozen cached slot. 10m would match the agent's maxSlotReferenceAge but
   would drop real data during any probe-side RPC outage longer than that.
3. Do you agree signature_valid should be written false (with signature_error = "signature
   verification disabled") when -verify-signatures=false, rather than keeping the constant true
   or adding a tri-state column? A tri-state means a ClickHouse migration and a lake change for a
   configuration that is not deployed.
4. Should I file the separate issue for the missing authority allowlist on geoprobe-target — that
   VerifyOffsetChain only checks self-consistency, so any freshly generated keypair can write
   attacker-chosen coordinates into location_offsets? I plan to file it and link it from the PR
   without acting on it.

[nikw9944]

security review findings:

• Critical: 0
• High: 1
• Medium: 0
• Low: 4

Security Review

Critical

None

High

• H1 [Authorization / DoS]: The slot floor is keyed on offset.SenderPubkey, but VerifyOffsetChain only proves the datagram was signed by offset.AuthorityPubkey — the two fields are unrelated in production (geoprobe-agent/main.go:468 and publisher.go:72 both pass a signing keypair and a different device pubkey to NewOffsetSigner, and the new newTestSigner helper does the same with two unrelated wallets). So any unauthenticated host can generate a throwaway keypair, set SenderPubkey to a real geoprobe's pubkey and MeasurementSlot to an arbitrarily large value, and the chain verifies. That one UDP packet raises the victim's floor to MaxUint64; every genuine offset from that probe is then dropped as slot_regressed until the entry ages out, and the attacker keeps it pinned by resending once per TTL. The diff turns a table that could previously be polluted into one where a legitimate probe's measurements can be silenced — a new capability, and this is the input the gate is supposed to be trusted with.
  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:472 (handleOffset -> floor.accept), controlplane/telemetry/cmd/geoprobe-target/main.go:289 (slotFloor.accept)
  • Recommendation: Key slotFloor.entries on offset.AuthorityPubkey — the key the signature is actually verified against — so a floor bucket can only be advanced by the holder of the corresponding private key. Add a test that a datagram signed by a fresh authority but stamped with a victim's SenderPubkey cannot move the victim's floor.

Medium

None

Low

• L1 [Configuration]: The floor's memory lifetime is *maxOffsetAge, a cache-tuning flag documented as "TTL for cached offsets", not as a security parameter. Setting it below maxFloorStall (e.g. -max-offset-age=5m) silently collapses the replay bound: an entry drops out and the next arriving datagram — possibly a capture — re-seeds the floor. Rejections also don't refresh lastSeen, so a stalled sender's entry always expires and cold-starts.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:143, main.go:325
  • Recommendation: Give slotFloor its own floorEntryTTL constant (>= maxFloorStall) instead of reusing *maxOffsetAge.

• L2 [Misleading invariant]: The comment claims an equal-RTT sample "would otherwise hold best forever", implying the < fix makes the cache replay-proof. It doesn't: an identical repeated value still lands in backup during the guard window and is promoted to best on expiry, and the cycle repeats indefinitely. The next maintainer may rely on a guarantee the code doesn't give; only the slot floor actually bounds this.

  • Location: controlplane/telemetry/internal/geoprobe/mincache.go:120
  • Recommendation: Reword to what the change does — an equal-RTT sample no longer restarts best's clock directly — and drop the "forever" claim.

• L3 [Resource exhaustion]: slotFloor.entries grows one entry per distinct SenderPubkey, which is attacker-chosen and free to mint; the only bound is the 5-minute sweep against a 1-hour TTL, and the per-source-IP rate limiter is bypassable with spoofed UDP sources. Not the binding constraint — the co-located MinCacheMap is keyed the same way and holds far larger values — but the new map inherits the exposure.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:296
  • Recommendation: If bounding is wanted, cap entries at a fixed count and drop offers from new senders once full; otherwise leave it and fix the caches map with it, not separately.

• L4 [Log flooding]: Every rejected offset emits an unconditional Warn with no dedup or sampling. Since the changelog states these lines are the only signal that a sender stopped being ingested, an attacker spraying rejects (spoofed sources evade the limiter) buries the one line an operator needs.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:473
  • Recommendation: Log at most one rejection per sender per interval (reuse the existing token-bucket shape), keeping the first occurrence and a suppressed count.

Summary

Input validation, ClickHouse writes (parameterized batch.Append), slot arithmetic (entry.slot-slot is guarded by the preceding slot > entry.slot case, so no underflow), lock discipline, gate ordering after signature verification, and the signature_valid/signature_error relabel (fail-closed for consumers filtering on it) are all clean. The one substantive issue is H1: the floor is keyed on an attacker-controlled field rather than the key the signature is verified against, which lets a single unauthenticated packet lock a legitimate geoprobe out of location_offsets.

[nikw9944]

architecture review findings:

• Critical: 0
• High: 2
• Medium: 3
• Low: 4

Architecture Review

Critical

None.

High

• [Correctness / replay bound defeated by its own GC]: Both rejection paths in accept return before entry.lastSeen = now, so a rejected sender's entry is never refreshed and sweep deletes it ttl (default 1h, inherited from -max-offset-age) after its last accepted offer. The next replay then hits the never-seen path and seeds the floor from itself. A capture replayed continuously against an offline probe is ingested for maxFloorStall (30m), rejected for 60m, then ingested again — roughly a 33% duty cycle, indefinitely, into the public location_offsets table. The doc comment at main.go:286 and the changelog both state the exposure is "one stale capture per sender per process restart", which is not what the code does.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:314 (with :320 and :143)
  • Recommendation: Move entry.lastSeen = now to immediately after the map lookup, before the switch, so any traffic (accepted or not) keeps the floor alive. Give the floor its own retention constant (e.g. floorRetention = 4 * maxFloorStall) instead of *maxOffsetAge. Note this removes the accidental recovery path for a sender whose RPC genuinely regressed more than maxSlotRegression; if that recovery is wanted, make it an explicit named rule ("reseed after N of continuous rejection") rather than a side effect of the RTT cache TTL, and fix the :286 comment and the changelog to state the real bound.

• [Security / unauthenticated key for a stateful gate]: VerifyOffsetChain proves only that AuthorityPubkey signed the payload; nothing binds SenderPubkey to it without a ledger lookup, which this daemon deliberately does not have. Keying the floor on SenderPubkey lets anyone self-sign one offset claiming a real probe's SenderPubkey with MeasurementSlot near 2^64 and lock that probe out permanently: every genuine offset then lands billions of slots under the floor and is dropped as slot_regressed, sustained by one packet per eviction period. This is distinct from the known allowlist gap (an attacker inserting their own rows) — it is a new lever that silences a legitimate sender, and the comment at main.go:36-41 calls the floor "unforgeable" without this caveat.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:289 (advance path :302-304)
  • Recommendation: Key slotFloor.entries by AuthorityPubkey — the key the signature actually authenticates — so a forger can only poison the floor belonging to their own key. Keep SenderPubkey in the log line. Update the :36-41 comment to say the floor is per signing key, not per claimed sender.

Medium

• [Configuration coupling]: newSlotFloor(*maxOffsetAge) ties replay-floor retention to a flag documented as "TTL for cached offsets; best/second-best tracking window". An operator tightening the RTT window to e.g. 10m unknowingly shortens the reseed period below maxFloorStall, worsening H1 to 30m accepted per 40m. The two lifetimes have nothing to do with each other.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:143
  • Recommendation: Use a dedicated constant derived from maxFloorStall, and log it at startup alongside max_floor_stall.

• [Test coverage]: slotFloor.sweep has no test at all, and no test drives accept -> stall -> sweep -> accept. The retention half of the state machine is exactly where H1 lives, so the suite reads as complete while covering only the acceptance half.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main_test.go:196
  • Recommendation: Add TestSlotFloor_RejectionKeepsFloorAlive: seed, advance past maxFloorStall, reject a repeat, call sweep(), then assert the same repeat is still rejected rather than reseeding.

• [Test coverage]: No test pins accept's documented precondition that an unverified slot must never move the floor. TestHandleOffset_DropsUnsignedOffset builds a fresh newSlotFloor per iteration and never inspects it, so reversing the verify/floor order in handleOffset would not fail any test — and given H2 that ordering is load-bearing.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main_test.go:51
  • Recommendation: Share one floor across the loop, feed a forged offset stamped with slot 2^40, then assert a genuine offset at slot 1_000_000 is still accepted.

Low

• [Readability / mislabel risk]: signatureValid := verifySignatures derives a public-table assertion from the flag rather than from the check result; it is correct only because the failure branch returns. A future path that logs and continues would write signature_valid=true for an offset that failed verification.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:448
  • Recommendation: Initialize signatureValid := false and set it to true on the line after VerifyOffsetChain returns nil.

• [Constant drift]: maxFloorStall's justification hardcodes the sender's "5m slot cache" in prose, but that value is geoprobe.SlotCacheTTL in an importable package. If it changes, the 30m bound silently stops matching the behaviour it is tuned against.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:49-56
  • Recommendation: Define maxFloorStall = 6 * geoprobe.SlotCacheTTL so the relationship is checked by the compiler, as maxSlotReferenceAge already does in geoprobe-agent.

• [Observability]: Every rejected datagram logs at Warn with no dedupe. The rate limiter permits 10 pps per source IP, so a replay flood from many sources is a log amplifier that buries the one signal these lines exist to carry ("this sender stopped being ingested"), and alerting requires counting lines rather than reading a field.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:473
  • Recommendation: Keep a rejected counter in floorEntry; log the first rejection per (sender, reason) and then at most once a minute, including the counter in the line.

• [Contract inconsistency]: accept's doc says callers must verify the chain first and that an unverified slot must never move the floor, but handleOffset calls it unconditionally, so -verify-signatures=false lets any datagram set floors.

  • Location: controlplane/telemetry/cmd/geoprobe-target/main.go:472
  • Recommendation: Skip the floor check when !verifySignatures (nothing is trustworthy in that mode anyway), or amend the :283-285 comment to say the precondition is unenforced in debug mode.

Summary

The stream-derived floor is the right shape for a daemon with no ledger access, but two properties it depends on do not hold: rejections let the entry age out and reseed from the replay itself (H1), and the key it indexes on is attacker-choosable, turning the gate into a per-probe silencer (H2). Both are small, local fixes; the mincache and signature_valid changes are sound and correctly tested.

[nikw9944]

Work Log — waiting_review

I'll start by reading the README and getting oriented.

Now implementing. Starting with the mincache fix:

Now the mincache test rewrite:

Now the slot floor in geoprobe-target:

Now handleOffset:

Now the CLAUDE.md invariant line:

Now let me run the full gates and commit before review.

Lint clean. Now the full Go build and test:

Both reviewers found the same two real defects. Verifying the premises before fixing:

Applying the fixes:

Verifying the two new tests fail without their fixes:

Now the reviews get posted, then Rust gates. Posting both review comments:

Now the full gates, including Rust:

Clean merge. Verifying the Go side still passes post-merge while Rust lint runs:

PR body is over the 3,500-character ceiling. Trimming:

Done. Draft PR #4308 is open against nikw9944/adhoc-413, working tree clean, nothing running in the background.

What shipped. geoprobe-target now drops replayed offsets using a per-signing-key MeasurementSlot floor derived from the offset stream rather than a ledger clock — the daemon holds no RPC connection, and RFC-16 makes that a design property. Two cleanups ride along: signature_valid stops asserting a check that did not run with -verify-signatures=false, and MinCache.Update stops restarting best's expiry clock on an equal RTT.

Review round changed the design in two places. Both reviewers independently found that keying floors on SenderPubkey was wrong: it is signed but unauthenticated, so a minted keypair stamping a real geoprobe's SenderPubkey with a huge slot would have locked that geoprobe out of location_offsets — a new denial capability the fix itself introduced. Floors are now keyed by AuthorityPubkey, the key VerifyOffsetChain actually checks against. The architecture reviewer also found that a rejected offer did not refresh lastSeen, so a sustained replay outlived its own entry and reseeded from itself roughly every TTL rather than once per restart. Both fixes have tests confirmed to fail when reverted.

Verification. make go-build, make go-lint-native (0 issues), make rust-lint (exit 0, re-run after the base merge), and go test -race ./controlplane/telemetry/... all pass. make go-test and make rust-test need Docker, which this environment lacks; running go test ./... directly leaves six packages failing on raw sockets, netlink and container requirements — I confirmed the identical failure set on a stashed clean tree. make e2e-test RUN=TestE2E_Geoprobe could not run at all. That gap matters here: this changes ingest acceptance, and a false rejection loses a measurement permanently rather than deferring it.

Disputed findings (both Low, both raised by both reviewers): rejection-log dedup, and capping the new map. The two log.Warn lines already adjacent in handleOffset are equally unthrottled, and the co-located MinCacheMap is keyed the same way with larger values — hardening only the new code would be inconsistent without fixing its neighbors, which is a separate change.

FOLLOW-UPS

• The missing probe-pubkey allowlist on geoprobe-target — any freshly generated keypair can still write attacker-chosen coordinates to location_offsets. Confirmed, described in the PR body, deliberately not filed: the operator is filing it because it spans this repo and malbeclabs/lake.
• Lake's geolocation handlers do not filter on signature_valid, so pre-malbeclabs/doublezero#4271 forged rows keep rendering on the public explorer. Lake-side, out of scope.
• rfcs/rfc16-geolocation-verification.md needs an accuracy pass — its instruction table lists UpdateProgramConfig as variant 13 where the implementation has it at 1, shifting every variant. Left untouched on operator instruction.
• geoprobe-target has no prometheus metrics; rejections are observable only through structured log lines. A counter with a reason label, matching geoprobe-agent's OffsetsRejected, is the natural follow-up.
• changelog.d/ and scripts/collate_changelog.py do not exist in this repo, so the fragment I wrote will not be folded into CHANGELOG.md automatically. Flagged in the PR body.
• Cold start remains: a never-seen key seeds its floor from its own first offer, so one stale capture is accepted per key per process restart. Documented in the code, not closed — closing it needs identity, which is the allowlist item above.

Fences: v4 (3 active)

STATUS: COMPLETE

--- Result: success | Session cost: $10.4614 | Turns: 76 | Tokens: 150 in / 67177 out | 2026-09-10 02:18:23 UTC ---

[nikw9944]

Work Log — waiting_review

I'll start by looking at what the changelog check actually requires.

Now commit and re-run the check the way CI does (against the PR base, post-commit):

Fixed and pushed as 61a8bfb5.

Root cause. The entry was written to changelog.d/nikw9944-adhoc-527.md, but this repo has no changelog.d/ directory on main and no tooling that reads one — the directory was created by this branch alone. .github/workflows/changelog-reminder.yml requires CHANGELOG.md itself to appear in git diff --name-only origin/$GITHUB_BASE_REF...HEAD. The CHANGELOG.md edits visible against main all came from the base branch, and #4308 is stacked on nikw9944/adhoc-413, so against its actual base this branch touched no changelog at all.

Fix. Moved the three bullets into the existing Geolocation list under ## Unreleased → ### Changes in CHANGELOG.md and deleted the changelog.d/ file. No prose changes to the entry.

Verification. Replayed the workflow's own logic locally against origin/nikw9944/adhoc-413: CHANGELOG.md is now in the changed-file set, and no offchain/ subproject is touched, so the per-crate arm is a no-op. I could not run the Go tests — the sandbox has no network and the pinned Go 1.25.11 toolchain isn't cached locally — but this commit changes only CHANGELOG.md, so no test is in scope for it.

One thing worth your attention: I wrote the original entry to changelog.d/ because the fleet writing-style guidance says changelog entries go there and "never in CHANGELOG.md itself." That guidance is wrong for this repo, which enforces the opposite in CI. Every future branch here will hit the same failure until the guidance is corrected or the repo grows real changelog.d/ tooling.

FOLLOW-UPS

Recommended next: get the fleet writing-style guidance amended to say that doublezero entries go directly in CHANGELOG.md under ## Unreleased. This is a one-line fix to standing policy that prevents a guaranteed red changelog check on every doublezero PR — higher value than anything else pending on this branch, and it needs an operator since I can't edit fleet policy myself.

Fences: v4 (3 active)

STATUS: COMPLETE

--- Result: success | Session cost: $0.8355 | Turns: 17 | Tokens: 26 in / 5914 out | 2026-09-10 02:24:16 UTC ---