mirror of
https://github.com/jmcorgan/fips.git
synced 2026-08-09 08:14:42 +00:00
Johnathan Corgan
7a97599921
The rekey suites' Phase 4 polled until the initiator-cutover count reached its value at phase entry plus two, while Phase 6 asserts an absolute minimum of four. On an unloaded host the ping phases can outrun the jittered first rekey cycle, so Phase 4 can begin with a single cutover on the books, release at three, and leave Phase 6 to lose a sub-second race against the remaining first-cycle cutovers. A rekey-outbound-only run failed exactly this way: five counted cutover lines by t=32.6s of container life, with the Phase-6 count snapshot at t~32.4s seeing three. Floor the Phase-4 wait target at four so a released wait guarantees the Phase-6 assertion — the docker-logs count is monotone over a container's lifetime. A genuine rekey stall still times out the bounded wait and fails Phase 6 with the real count. Also drop the second-cycle framing from the comment, the phase banner, and the assertion description: with rekey timers resetting at each cutover a second cycle cannot begin inside this test's window, so the counted events are first-cycle cutovers spread across the topology's links, emitted once or twice per completed link rekey depending on which side's promotion path logs them.