itsgoin/docs/TODO-hardening.md

DOS Hardening TODO

Identified during v0.4.0 audit (2026-03-21). Implement before v0.4.1.

CRITICAL — Lock Contention (v4-introduced)

L1. ManifestPush discovery holds cm lock during network I/O (connection.rs:4847-4981)

• Spawned task grabs cm lock, calls send_post_fetch (QUIC I/O), waits for response — all while locked
• Every connection operation queues behind it (5s+ freeze possible)
• Fix: Gather connection handle before locking cm. PostFetch outside lock. Brief re-acquire for DB writes.

L2. Pull request handler holds lock during filtering (connection.rs:1855-1905)

• Loads ALL posts, loops through checking visibility + timestamps while holding storage lock
• 50K posts = 500ms+ lock hold
• Fix: Load posts under lock (brief), release, filter without lock (CPU only), re-acquire briefly for is_deleted() on filtered subset.

L3. Pull sender's second lock too long (connection.rs:1650-1721, 1572-1624)

• After receiving posts: store + add_upstream (count query each) + update_last_sync — all under one lock
• 100 posts = 100 inserts + 100 count queries + 20 author updates
• Fix: Split into two brief locks. First: bulk store posts. Second: batch upstream adds + last_sync updates. Collect unique authors during first lock.

L4. Per-post engagement lock acquisitions (connection.rs:1777-1833)

• Lock acquired/released 100 times in tight loop (once per post)
• Each acquisition blocks behind other tasks
• Fix: Batch writes. Collect all engagement results, acquire lock once, write all. Network I/O already outside lock.

L5. Stale follows query (node.rs:2528-2530) — LOW

• get_stale_follows every 60s, brief query, acceptable
• Fix (optional): Add index on follows(last_sync_ms) if missing

HIGH Priority — DOS

1. Stream handler cap (connection.rs:4252, 4270)

• Max 10 concurrent workers per connection via Semaphore
• Excess streams wait, not spawned unbounded

2. Slot index memory bomb (connection.rs:5754-5792)

• Soft 1K slot limit per post
• Author can sign capacity increase that propagates via BlobHeaderDiff
• Without author signature, cap stays at 1K
• Consider thread-split pattern for overflow (already exists for 16KB comments)

3. ManifestPush amplification (connection.rs:4877-4936)

• Custom ManifestPush for new posts: only deliver [new_post_id, previous_post_id]
• Each CDN partner updates their own local manifest copy
• Same diff pattern useful for N+10 updates
• Lower bandwidth, low-priority background task

MEDIUM Priority

4. Post list pagination (connection.rs:1857)

• Limit to 200 posts per pull response
• ~100KB memory, <5ms lock hold
• Next sync cycle catches remainder via since_ms timestamps

5. Eviction candidate cap (storage.rs:3678-3737)

• Limit to 100 candidates per batch
• ~40KB memory, <5ms lock hold
• Next 5-min cycle catches more if needed

6. Payload element abuse — CDN consensus check

• Before accepting a large engagement update, check 1-2 CDN neighbors
• "Does your header for this post look like this?" If not → reject
• Attacker must compromise multiple CDN nodes to pass
• No trust scoring needed — just peer corroboration

7. Lock acquisition timeouts (connection.rs: throughout)

• 5-second timeout on storage lock acquisition
• On timeout: skip operation, try next cycle
• Log: operation name, wait duration, who holds the lock
• Add last_lock_holder: AtomicU64 storing hash of acquiring function name

8. Discovery task cap (connection.rs:4938-4980)

• One discovery task per peer at a time
• AtomicBool flag per connection, skip if already running

LOW Priority

9. Engagement rate limiting

• Self-claimed: max 3 emoji + 1 comment per 10 seconds
• Chain-propagated: CDN consensus check from #6 applies
• Process only first 100 ops per BlobHeaderDiff message

10. Mesh stream spawn cap (connection.rs)

• Same as #1 — 10 max concurrent handlers per connection
• Supplements auth rate limiter (which handles connection-level, not stream-level)

11. Retry backoff per target

• Start at 5 seconds, triple on each failure
• 5s → 15s → 45s → 135s → 405s → 1215s → 3645s → 10935s → 14400s (cap at 4hr)
• 8 failures to hit max backoff
• Reset to 5s on success
• Track per target peer, not global

---

Security Hardening TODO

Identified during v0.4.0 security audit (2026-03-21).

CRITICAL — Immediate (before next public release)

S1. Comment signature verification — ONE LINE FIX (connection.rs:5711-5724)

• verify_comment_signature() exists in crypto.rs but is NEVER called on receipt
• Add if !crypto::verify_comment_signature(...) { continue; } before store_comment()
• Infrastructure exists, just not wired up

S2. Reaction removal auth check — TWO LINE FIX (connection.rs:5708-5709)

• RemoveReaction accepts from any sender, no auth
• Add: if *reactor == sender || sender == payload.author { ... }
• Same pattern already used in EditComment/DeleteComment

S3. Reaction signature — ~30 lines (types.rs, crypto.rs, connection.rs)

• Reaction has no signature field — anyone can fake reactions from any NodeId
• Add signature: Vec<u8> to Reaction struct (#[serde(default)] for compat)
• Sign (reactor + post_id + emoji + timestamp) with reactor's ed25519 key
• Verify in handle_blob_header_diff before storing
• Follow existing sign_comment / verify_comment_signature pattern

S4. BlobHeader author verification — ~5 lines (connection.rs:5821-5836)

• Header rebuild uses payload.author without checking against stored post author
• Look up actual author from storage.get_post(&payload.post_id)
• Use stored author, not payload-claimed author

HIGH — Short-term

S5. PostId verification in all paths (connection.rs)

• PostPush verifies with verify_post_id() but some pull paths don't
• Audit all store_post_with_visibility call sites
• Ensure verify_post_id() called before each store

S6. Slot write protection — self-healing signature system (connection.rs:5749-5803)

• Problem: any peer can overwrite encrypted slots with garbage
• Solution (two layers):
  1. CDN tree membership check: only accept slot writes from peers in post_downstream or post_upstream for that post. Rejects random peers.
  2. Self-healing signatures: participants sign their own slot writes with the slot key (derived from CEK) and keep a local copy. On diff check, if their slot was overwritten with something they didn't sign, they re-write their signed version. Other participants verify signatures — keep the signed version, discard unsigned garbage. The legitimate version propagates through the CDN tree. Attacker must keep overwriting forever; the real version keeps coming back from every CDN node that received it.
• Relay nodes can't verify signatures (don't have CEK) but pass through all writes — participants do client-side verification on decrypt

S7. Comment edit/delete cryptographic proof (connection.rs:5726-5736)

• Currently "trust-based" — checks sender == author at transport layer
• QUIC connection IS authenticated (iroh ed25519), so sender identity is verified
• Risk: compromised relay node
• Fix: require new signature over edited content (editor proves they hold private key)
• For post-author deletes: require post author's signature over delete request

S8. Pull sync follow list privacy (connection.rs:1846-1915)

• PullSyncRequest sends entire follow list unencrypted to every sync peer
• Every mesh peer learns your complete social graph
• Options:
  • Accept and document (mesh peers are semi-trusted infrastructure) — RECOMMENDED for now
  • Bloom filter: probabilistic set, leaks less, some irrelevant posts received (acceptable bandwidth cost)
  • Long-term: oblivious transfer / PIR (heavy crypto, probably not worth it for social network)

MEDIUM — Design review

S9. Nonce reuse guard (crypto.rs:54-56)

• ChaCha20-Poly1305 catastrophic on nonce reuse
• RNG is reliable on modern OS (getrandom syscall)
• Add sanity check: if nonce is all zeros after generation, panic rather than encrypt
• One-line guard

S10. Slot timing metadata leakage (connection.rs:5757, 5776)

• header.updated_at changes on slot writes, leaking WHEN engagement occurs on private posts
• Passive observer can correlate timestamps with known user behavior
• Fix: round updated_at to 10-minute buckets for private posts
• Or batch slot writes on fixed schedule rather than immediately

S11. Per-author engagement rate limiting (connection.rs:5699-5725)

• A peer can send 10,000 fake reactions in one BlobHeaderDiff
• Cap ops per message (100 max per DOS hardening #9)
• Deduplicate by (reactor, post_id, emoji) — storage already does ON CONFLICT DO UPDATE
• Combined with reaction signatures (S3), fake NodeId reactions become impossible

LOW

---

Data Cleanup TODO

D1. post_downstream not cleaned on post delete (storage.rs delete_post)

• When a post is deleted, downstream registrations stay forever
• Fix: add DELETE FROM post_downstream WHERE post_id = ?1 in delete_post()
• Also add: DELETE FROM post_upstream WHERE post_id = ?1
• Also add: DELETE FROM seen_engagement WHERE post_id = ?1
• One-line fixes each

D2. Document BlobHeader-table relationship (storage.rs store_blob_header)

• Header JSON is a snapshot, reactions/comments tables are authoritative
• They can temporarily diverge (BlobHeaderResponse arrives with newer header than tables)
• Header rebuilt from tables on next engagement op
• Add clarifying comment to store_blob_header

---

Low Priority

S12. Hex parse error logging (web.rs:110-119)

• Malformed hex strings silently return 404
• Add debug logging for malformed inputs

S13. Edit comment signature consistency (storage.rs:4338-4343)

• edit_comment updates content without updating signature
• If signature verification (S1) is enabled, edited comments would have invalid signatures
• Fix: add signature parameter to edit_comment, re-sign edited content