Regression action fails in merge-queue

[dougch]

Security issue notifications

If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.

Problem:

The regression GHA hasn't been flaky before, but with merge-queues on, it has failed 3 times in a row. Oddly, it passes to make it into the queue...
example

Run cargo test --release --manifest-path=tests/regression/Cargo.toml
  cargo test --release --manifest-path=tests/regression/Cargo.toml
  shell: /usr/bin/bash -e {0}
  env:
    PERF_MODE: diff
    Finished `release` profile [optimized + debuginfo] target(s) in 0.03s
     Running unittests src/lib.rs (tests/regression/target/release/deps/regression-1c573c1ab414aa48)
running 3 tests
test tests::test_session_resumption ... FAILED
test tests::test_rsa_handshake ... FAILED
test tests::test_set_config ... FAILED
failures:
---- tests::test_session_resumption stdout ----
thread 'tests::test_session_resumption' panicked at src/lib.rs:193:13:
assertion `left == right` failed
  left: 1
 right: 2
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- tests::test_rsa_handshake stdout ----
thread 'tests::test_rsa_handshake' panicked at src/lib.rs:193:13:
assertion `left == right` failed
  left: 1
 right: 2
---- tests::test_set_config stdout ----
thread 'tests::test_set_config' panicked at src/lib.rs:193:13:
assertion `left == right` failed
  left: 1
 right: 2
failures:
    tests::test_rsa_handshake
error: test failed, to rerun pass `--lib`
    tests::test_session_resumption
    tests::test_set_config
test result: FAILED. 0 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Error: Process completed with exit code 101.

Solution:

A description of the possible solution in terms of S2N architecture. Highlight and explain any potentially controversial design decisions taken.

• Does this change what S2N sends over the wire? If yes, explain.
• Does this change any public APIs? If yes, explain.
• Which versions of TLS will this impact?

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?

[dougch]

The action is doing some manual git work, and was written specifically for PR https://github.com/aws/s2n-tls/actions/runs/12285802421/workflow#L21