My "reproducible" build kept returning the same hash after the code changed. That was the bug.

The ZeroTrust supply-chain security scanner, developed for the Zero Dependency Hackathon, faced unexpected challenges during its testing phase. Despite passing all five checks that the tool designed to detect issues like phantom packages, typosquatting, and obfuscated payloads, it began to raise questions about its own reproducibility.

After multiple successful runs of the build, the identical hash produced by the process started to feel suspicious, as it did not align with the expected outcome of a clean build. Upon investigation, the source code changes made during the testing sessions became evident, revealing that the reproducible build hash was changing even when the code remained unchanged.

This led to the conclusion that the hash was not accurately measuring the integrity of the code but was instead being influenced by various factors like documentation edits. To address this issue, the tool was rebuilt with additional flags, ensuring a true reproducible build by disabling the inclusion of version control information in the binary.

The corrected build hash was verified to be identical across multiple runs, confirming the success of the fix. However, another challenge arose when attempting to run the race detector on the Windows environment. The race detector required a working 64-bit C compiler, which was not available on the developer's local MinGW toolchain.

This prevented the verification of the tool's own claim of being free from data races on the development platform. Rather than attempting to modify the toolchain, the decision was made to run the race detector on a different environment, specifically a Linux-based Docker container, where it successfully completed without any issues.