A technical paper is stronger when another investigator can inspect the exact experiment rather than reconstructing it from abbreviated listings. The expanded artifact therefore includes the provider source, the original client, the callback harness, the integration harnesses, configuration generation, result records, and reference snapshots. This chapter explains how these pieces support reproduction and where host dependencies remain.
The implementation directory contains executable source and scripts. The results directory contains observed outputs. The references directory contains downloaded documentary material and provenance. This organization helps distinguish a test definition from the record produced by running it. A result file should not be treated as a replacement for the script that generated it.
The paper’s rendered HTML and PDF are also kept alongside their generating sources. This makes presentation changes reviewable and allows the table of contents and page numbers to be regenerated consistently. The original shorter edition is archived separately so that the expanded edition does not erase the earlier deliverable.
cd room4/papers/psc ./implementation/extended-build.sh cat results/extended-tests.json cat results/extended-build.log
The command compiles the provider and client, runs the eight baseline checks, compiles and executes the direct callback test, and runs the 37-case integration extension. It requires a Linux C toolchain, pkg-config, OpenSSL development files, Python 3, and the platform dynamic-loader interface used by the callback test. It does not install the module into a system directory.
The generated configuration uses the current absolute build path. Rebuilding after a move is therefore part of the reproduction procedure. Copying an old configuration file without regenerating it could point at the wrong module, undermining the interpretation of a successful command. The script is designed to remove that ambiguity.
The saved OpenSSL version output records the runtime and build information reported by the installed executable. The compilation uses pkg-config to obtain headers and libraries. A reproducing investigator should check that those development files correspond to the intended runtime rather than assuming that every tool named openssl on the machine uses the same installation.
For broader comparative work, additional environment fields should be recorded: compiler version, operating-system release, architecture, relevant environment variables, and module checksum. The expanded artifact includes environment observations and integrity manifests, but it does not claim to recreate an entire virtual machine. A clean-machine reproduction remains a distinct and valuable exercise.
The twelve OpenSSL manual sources are pinned to the openssl-3.5.5 tag rather than downloaded only from a moving documentation page. Plain-text conversions are included for offline reading. The two PDF references are the NIST hash standard and the Trail of Bits assessment. The manifest records source URLs, retrieval date, and file hashes. This helps a reader distinguish the exact material used in the study from later revisions.
A snapshot is especially important for configuration semantics. The paper explicitly compares a historical assessment with a later documented version without assuming that their observations describe the same release. Preserving the reference version makes that qualification inspectable rather than relying on a vague statement that “the documentation says so.”
Repeating the scripts on the same host is a narrower achievement than reproducing the result independently on another host. The current results demonstrate the former and provide material for the latter. An independent reproduction could expose assumptions about library search paths, compiler options, platform loading behavior, or packaging that were invisible on the original machine.
For this reason the paper does not infer broad portability from one successful build. It provides a method for checking portability: rebuild, run the same positive and negative tests, inspect provider identity, and compare the result records. Differences should be analyzed rather than dismissed as environmental noise.
Result files should be regenerated after implementation changes and identified with the implementation they describe. Editing a test expectation merely to make a failure disappear would damage the evidential value of the study. When behavior changes intentionally, the requirement and rationale should be updated together with the test.
The saved JSON records contain expected conditions and observed success status for the integration cases. The callback log reports its completed assertion count. These records are useful, but they remain outputs of local software. They are not externally certified measurements. The paper’s claims are bounded accordingly.
An independent reviewer can begin by reading the provider source before examining the claimed outcomes. The reviewer can trace initialization and teardown, identify how backend selection is constrained, and check the guard in finalization. Running the baseline suite then establishes the ordinary integration path. Running the callback harness provides more targeted evidence about the identified boundaries.
A useful final exercise is to propose an untested failure case and explain why the current suite would or would not detect it. This turns reproduction into critical evaluation rather than mechanical execution. Examples include allocation failure, different suffixes after context duplication, and concurrent threads sharing provider-wide resources. The paper explicitly leaves these questions available for further work.