Exact

Exact Union RegExp

Repository files (latest commit first)

Filename	Latest commit message	Latest commit date
Transaction Science 79a94d3d94 wai_pq_vectors fits Windows' 1 MiB main-thread stack: the hybrid key's ML-DSA key on the heap, and the conformance leg's 8 MiB link flag gone ... wai_pq_vectors verify, in the debug build the conformance workflow runs, stopped with STATUS_STACK_OVERFLOW on Windows (6ca202b8a), and the corpus step's Windows leg was linked with an 8 MiB main-thread stack to pass. The cause is in wai's own code, not in RustCrypto's: a pq_sig::HybridKey held its ExpandedSigningKey<MlDsa65> by value, about 47 KiB (the matrix and vectors in the NTT domain), and an unoptimised build gives every key a function makes or moves a slot of its own. corpus::logs makes and moves dozens; under ulimit -s on the Framework the tool needed more than 3.3 MiB of main-thread stack, and gdb at the overflow found that one frame past 1 MiB on its own. The key now holds the expanded key in a Box: logs' frame is 32 KiB, and the tool needs about 0.75 MiB, most of it ML-DSA's key generation in the crate's own unoptimised frames (SigningKey::from_seed, 270 KiB), which wai cannot shrink. The keys, the signatures and the corpus are the same bytes: wai_pq_vectors verify regenerates vectors.json byte for byte and every case reaches its verdict at ulimit -s 1024, and the pq_sig library tests and tests/pq_signatures.rs pass. A thread with a stack of its own would have hidden the frame, not removed it, and left every other caller of the library with it. The 8 MiB link flag comes out of wai-conformance.yml. It was a stand-in for this fix, and kept, it would hide from the Windows leg any other tool or test that outgrows the 1 MiB a user's build of it gets on Windows, which is what that leg is there to see; it also gave the corpus step rustc flags no other step has, so cargo compiled every crate of the step again. The workflow's comment now says the tools run on each platform's own main-thread stack. tests/pq_signatures.rs ran its generation and verification on a 64 MiB thread. It now gives them 1 MiB, what Windows gives a main thread, so an unoptimised build that outgrows it fails on every leg, not on Windows alone. With the key planted back by value, that test fails (stack overflow). On cbio-device-0000 (Windows x86_64, pwsh 7, debug builds linked with the platform's default 1 MiB main-thread stack, no RUSTFLAGS): main's wai_pq_vectors verify stops with STATUS_STACK_OVERFLOW (0xC00000FD); with this change it passes, and with its stack reserve set lower by editbin it still passes at 768 KiB and stops at 704 KiB, as under ulimit on Linux. The corpus step as the workflow runs it (wai-conformance-lists.py corpora --verify, python3 from a venv as the leg makes it), without the flag, passes every corpus there, pq-signatures among them. On the Framework, the pq_sig library tests, synthesis::pq_tests and tests/pq_signatures.rs pass as the hybrid-signatures step runs them; wai breaking against main finds no break. Co-Authored-By: Claude Opus 5.5 <[email protected]>		2026-11-10 03:20:49 -05:00
..
wai-conformance	wai: sink-evaluated predicates and per-session ad tracks — targeting and frequency caps decided on the sink from its own state, and a session's own ad bound into a room's ad frame	2026-11-09 21:15:45 -05:00
workflows	wai_pq_vectors fits Windows' 1 MiB main-thread stack: the hybrid key's ML-DSA key on the heap, and the conformance leg's 8 MiB link flag gone	2026-11-10 03:20:49 -05:00