* Heal peer-ID rotation: rebind link on verified announce, retire ghost
When a peer relaunches it rotates its ephemeral peer ID, but a
still-open BLE connection kept its stale peripheral/central→peerID
binding for the reachability retention window (~45-60s). Until it aged
out, the other side showed a duplicate ghost peer and dropped the
rotated peer's direct announces as spoofing attempts.
Root cause: the ingress guard rejected a direct announce whose claimed
sender differed from the link binding before signature verification
could ever see it, so the binding could never heal.
- Ingress guard: let a mismatched direct announce through, attributed
to the claimed sender; REQUEST_SYNC keeps the strict binding check.
- Bind sites: raw (pre-verification) announces may only bind unbound
links, never rebind bound ones — rebinding now requires the announce
handler's signature verification to pass.
- On a verified direct announce whose ingress link is bound to a
different peer, rebind the link to the announced ID and retire the
rotated-away ID immediately (registry + gossip + UI), mirroring
handleLeave.
- BLELinkStateStore.bindPeripheral: drop the previous peer's reverse
mapping on rebind so the retired ID no longer claims the link.
Fixes#1387
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Contain forged-directness rebinds: no identity steal, per-link cooldown
The announce signature does not authenticate directness (TTL is
excluded from signing because relays mutate it), so a bound peer could
replay another peer's fresh signed announce with its TTL restored and
reach the rotation rebind path. Contain what such a replay can do:
- Refuse a rebind when the claimed identity already owns another live
link — a replayed announce can no longer steal a connected peer's
binding or route its directed traffic to the replaying link.
- Allow at most one rebind per link per cooldown window (60s) so two
identities cannot fight over a link in a replay flip-flop, with each
flip retiring the other peer.
A replay against an identity with no live link remains possible, but
that capability already exists today on unbound links, where any raw
direct announce binds pre-verification.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Harden REQUEST_SYNC and stop gossip-sync re-send loops
Two fixes from an end-to-end review of the sync path:
Efficiency: the GCS filter (400B, p=7) covers ~355 packet IDs, but stores
hold up to 1000 messages + 600 fragments + 200 files. Once a mesh
accumulates more than the filter can cover, responders re-sent the entire
older tail to every requester every round — ~120KB per pair per 30s during
file transfers, dropped by dedup after the airtime was already burned.
Requesters now stamp the dormant sinceTimestamp TLV with the oldest
timestamp their filter covers, and responders skip older packets (announces
exempt: they carry the signing keys needed to verify everything else).
Periodic sync also sends one request per type schedule instead of a union
filter, so fragment floods can't crowd messages out of the filter budget.
Security: a ~40-byte unsigned REQUEST_SYNC with an empty filter could elicit
a full store replay (~900KB) — an unauthenticated >10,000x amplification
vector, repeatable in a tight loop and relayable with crafted TTL to fan the
drain out of every reachable node. Requests now require ttl == 0, a valid
signature from the claimed sender's announced signing key, and a matching
link binding; REQUEST_SYNC is never relayed regardless of TTL; and responses
are rate-limited per peer (8 per 30s sliding window, ~3x the legitimate
cadence).
Cross-platform: verified against bitchat-android — it signs REQUEST_SYNC and
sends SYNC_TTL_HOPS = 0, so both gates hold; it neither sends nor honors
sinceTimestamp yet, so mixed pairs keep today's behavior with no regression.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* Address Codex review: enforce no-relay on route path, exact since-cursor
Two P2 findings from Codex on the REQUEST_SYNC hardening:
- Route-forwarding bypass: handleRequestSync's early return for a rejected
(nonzero-TTL / unsigned) request still fell through to
forwardAlongRouteIfNeeded, which relays any routed packet with ttl > 1
regardless of type. The no-relay invariant was only enforced on the flood
path. BLERouteForwardingPolicy now suppresses REQUEST_SYNC outright, so a
crafted request with a route and TTL headroom can't be forwarded to the
next hop either.
- Inexact since-cursor: GCSFilter.buildFilter trimmed by hash order when the
encoding overflowed the byte budget, so the cursor (computed from the
untrimmed prefix) could claim coverage of timestamps whose packets were
dropped from the filter — re-sending exactly those every round. buildFilter
now trims from the input tail (oldest, since candidates are newest-first)
and reports includedCount; the cursor is derived from that, so the covered
set is always a contiguous newest-prefix and the cursor is exact.
Adds GCSFilter includedCount coverage (full vs trimmed), a route-forwarding
test for REQUEST_SYNC, and makes the truncated-cursor test robust to trim
variance. Full suite: 1029 tests pass.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Refactor BLE transport event handling
* Make image output paths unique
* Keep queued Nostr read receipts alive
* Refine BLE ingress fanout
* Rediscover BLE service after invalidation
* Extract BLE notification retry buffer
* Extract BLE inbound write buffer
* Extract BLE fragment assembly buffer
* Tidy secure log handling from device run
* Allow self-authored RSR ingress replies
* Harden read receipt queue test timing
---------
Co-authored-by: jack <jackjackbits@users.noreply.github.com>
