Harden pre-latch ANNOUNCE handling and bound resend/ttl edge cases

[gistrec]

Summary

Five robustness fixes from a pre-release audit. Each was reproduced locally and is covered by a test that runs on Linux/macOS. Build is clean under -Wall -Wextra; all 10 ctest cases pass.

The headline fix is a one-packet DoS: before a receiver latched a session, a single forged ANNOUNCE could kill filecast receive while it was still waiting for a sender.

Fixes

🔴 Pre-latch ANNOUNCE DoS (Receiver.cpp)

Before a receiver latched a session, a forged ANNOUNCE with an invalid file_size/chunk drove announceValid() to a fatal exit(2) — so one unauthenticated datagram killed filecast receive in the very window it spends "Waiting for a sender...". The post-latch path already guarded against this (see e2e_hijack); the pre-latch window did not.

• Validate with the side-effect-free Protocol::announceInRange() before latching or refreshing the deadline.
• Ignore an invalid pre-latch ANNOUNCE (warn + keep waiting) instead of exiting, mirroring the same-session guard.
• Remove the now-unused announceValid().

Reproduction: a single file_size=0 ANNOUNCE made the receiver exit 2 in ~0.1s; it now logs a warning and waits out its full ttl.

🟡 RESEND burst ignored Ctrl+C / deadline (Receiver.cpp)

The recovery re-request loop checked g_interrupted and the wall-clock deadline only in its outer loop, so re-requesting a large missing set (with --rate/--delay-ms pacing) left the receiver unresponsive for many seconds. Now checked inside the burst too.

🟡 32-bit size_t overflow on max-size files (Receiver.cpp, Protocol.hpp, Sender.cpp)

Two overflows on the same 4 GiB boundary, both harmless on a 64-bit size_t:

• MAX_FILE_LENGTH: 4ULL*1024*1024*1024 wraps to 0 on a 32-bit size_t, making the receiver reject every non-empty file. Use the exact v3 wire limit 0xFFFFFFFF, which fits size_t on every target.
• totalParts() (follow-up from review): with the limit fixed a max-size ANNOUNCE is now accepted, but (file_length + chunk_size - 1) / chunk_size still wraps a 32-bit size_t for file_length in the top chunk_size bytes of the range, collapsing the part count to ~0 — the receiver then rejects every data part (part >= 0) and calls the transfer 0/0 complete, and the sender (same inlined expression) ships 0 parts. Switched to overflow-safe ceiling division (file_length / chunk_size + (remainder != 0)) in the shared helper, with Sender routed through it. Contained by the existing part >= total bound, so a correctness bug, not OOB/DoS.

🟢 --ttl overflow guard (Main.cpp)

--ttl was only checked for > 0; ttl*10 seconds (the sender's resend-phase deadline) overflows a steady_clock time_point in nanoseconds at absurd values. Capped at 86400 (24h).

🟢 Zero-length datagram drained the resend phase (Sender.cpp)

serveResends() treated a zero-length datagram as a timeout (result <= 0), letting a peer spraying empty packets drain the resend phase early. Split result < 0 (timeout) from result == 0 (ignore), mirroring the receiver's length == 0 handling.

Tests

• New e2e_prelatch: fires two poison ANNOUNCEs (empty file, out-of-range chunk) at a receiver before the real sender starts, checks it survives, then requires the real transfer to complete and verify.
• Updated comments in e2e_hijack.sh / hijack_proxy.py that referenced the removed announceValid().
• TotalPartsBoundaries unit test now pins the 0xFFFFFFFF max-wire-size counts (64- and 65489-byte chunks) — a real regression guard on 32-bit builds, a smoke test on 64-bit.
• ctest: 10/10 pass (was 9, plus e2e_prelatch).

Deferred (follow-up issues)

Unbounded sent_part growth under a full-loss RESEND storm, and three Windows-only items (WSAGetLastError in send diagnostics, WSAStartup ordering vs inet_pton, symlink guard on .part.idx) that need CI/Windows to verify.