mirror of
https://github.com/openglow-org/forgefirm.git
synced 2026-09-29 01:21:16 -07:00
ScottW514
83686fc712
The test judges each connection by the kernel's TLS counters and the crypto engine's interrupt, and both are the machine's, not the connection's. On image 20260928175056's campaign the test before it restarted forgectrl, the operator's panel (six HTTPS connections from the bench PC) reconnected in the same second as aes-1.3#1, and the kernel counted 7 sessions each way where the test wanted exactly 1; the connection itself chose AES-128-GCM, carried the page byte for byte, and counted no decrypt error. _fetch now also reads the machine's accepted TCP connections (PassiveOpens, shared by both families); a case whose window saw any connection but its own is measured again, up to 30 times after a pause drawn from 0.1 to 0.9 s (so no steady poller, such as a page polling this suite once a second, stays in step with it), and fails if every window was contested. The judgments are unchanged: exactly one session each way for a cipher the kernel seals, none for CBC, the engine's interrupt counting the AES records and not the ChaCha20 ones. Proof: pyflakes clean. On the bench reference, image 20260928175056, with an openssl client connecting to :443 every 0.25 s for the first 6 s of the run and the drill polling this suite once a second: the image's test fails (desktop-1.2 counted 2 sessions each way), the fixed test passes with contested windows measured again (at most 4 attempts a case), and passes again without the extra clients (at most 4). Acceptance: the change is forgectrl.tls-records itself; tlsrec.py holds no other test, so no other fingerprint moves.