Verify the source and reference files against the supplied manifest before changing the experiment. Record the OpenSSL executable version and the development package selected by pkg-config. If several OpenSSL installations exist on the machine, identify the one used by both compilation and execution. Build in the local project directory; do not install the teaching module into a system provider directory merely to reproduce the tests.
./implementation/build.sh cat results/tests.json cat results/providers.txt
There should be eight successful baseline checks. Confirm that the programmatic client reports provider=edu. Compare the abc digest with the known value in the paper. Confirm that the expected property failure is recorded as a passing negative test rather than being ignored.
./implementation/extended-build.sh cat results/extended-tests.json tail -n 2 results/extended-build.log
The saved log in this edition contains the observed run. When reproducing, redirect output to a new file if the original record must be preserved. The callback test should complete its assertions, and the integration harness should report 37 cases. If a run fails, preserve the compiler output, command, environment, and error text before changing the implementation.
| Review area | Question |
|---|---|
| Initialization | Are outputs returned only after required provider resources exist? |
| Partial failure | Can every allocated resource be released on the path where a later step fails? |
| Advertisement | Does each algorithm table remain alive for as long as the core may use it? |
| Dispatch | Do function identifiers match callback signatures? |
| Input handling | Are byte lengths preserved across wrapper and backend calls? |
| Output handling | Are capacity, written length, and backend finalization ordered correctly? |
| Duplication | Does a new operation own independent mutable state? |
| Policy | Is the backend selection explicit and consistent with the intended assurance? |
| Cleanup | Are operation contexts released before the resources they depend on? |
Feed different suffixes to duplicated contexts and compare against two expected values. Introduce controlled allocator failures and record whether cleanup remains correct. Build with memory instrumentation and rerun the same deterministic tests. Add an in-process multithreaded client with independent digest contexts. These are suggested extensions, not completed experiments in this edition.
For a performance project, implement both direct-default and bridge paths in the same executable. Separate provider loading, method fetching, and warm digest processing. Report message sizes, update fragmentation, iteration counts, uncertainty, and output validation. Avoid using the large-message functional case as a performance measurement: no timing was recorded for that purpose.
The PDF explains the reasoning; the source defines the implementation; the scripts define the procedure; the result files record observed execution. If these disagree after an edit, regenerate the affected artifacts and update the claims. An archived result should never be presented as evidence for changed code without rerunning the relevant tests.
| Completed in this edition | Still proposed or outside scope |
|---|---|
| Dynamic provider and application client. | Independent SHA-256 implementation. |
| Eight baseline and 37 extended integration cases. | Exhaustive state-space exploration. |
| Direct callback capacity and parameter checks. | Allocation-failure campaign and sanitizers. |
| Sixteen independent parallel processes. | In-process thread-safety stress tests. |
| Version-pinned reference collection. | Independent clean-machine reproduction. |
| Functional results on OpenSSL 3.5.5. | FIPS validation or production security approval. |
This distinction is the final acceptance criterion for the paper itself: every experimental claim should correspond to an executable procedure and a recorded result, while proposals should remain visibly labeled as proposals.