Component output is not byte-reproducible for identical inputs

[starsang1995]

Summary

Running componentize-py componentize twice with the same command and byte-identical
inputs can produce valid but byte-different WebAssembly components. This prevents use in
content-addressed build and artifact-verification pipelines.

I would like maintainer guidance on the shape of an opt-in reproducible-build mode before
opening the larger implementation PR. A small independent PR that makes WASI stub-adapter
emission deterministic is ready separately.

Reproduction

Using current main at aa3d6d1, Rust 1.95.0, WASI SDK 34, and the repository sandbox
example:

for output in first.wasm second.wasm; do
  componentize-py \
    -d sandbox.wit \
    componentize \
    --stub-wasi \
    guest \
    -o "$output"
done

shasum -a 256 first.wasm second.wasm
cmp first.wasm second.wasm

Expected: both files are byte-identical.

Actual: the files differ while remaining valid components.

Investigation

An experimental --reproducible implementation fixed or controlled all of the following:

• build-time secure and insecure randomness;
• build-time wall and monotonic clocks;
• PYTHONHASHSEED;
• CPython allocator initialization with PYTHONMALLOC=malloc_debug;
• bytecode cache writes;
• WASI stub-adapter map iteration order;
• metadata on generated helper, standard-library, bindings, and input trees.

Even with all of those controls, two current-main outputs still differed: one run produced
19,323,845 bytes, the other 19,325,725 bytes, with the first difference at component offset
9.

I then repeated the experiment with ambient user/system site-packages excluded and the
same input, generated bindings, bundled helpers, and standard library exposed through stable
host directories. The outputs still differed (292a9320... versus f35b0e6d...). Both had
the same 208-page memory and 1,710 data segments, but reconstructing linear memory from those
segments found roughly 4.1 million differing bytes across 141 pages.

The difference is localized more narrowly than an encoder or linker problem:

• both outputs contain 205 top-level component sections;
• 204 sections are byte-identical;
• only the first embedded core module differs;
• within that module, all type, import, function, table, global, export, and code sections are
  byte-identical;
• only the memory snapshot/data section differs.

Additional two-run probes showed identical values for Python string hashes, random, wall and
monotonic clocks, process/thread identity, visible directory ordering, generated Symbols, and
the component immediately before pre-initialization. Full linear-memory fingerprints taken
inside the guest were identical after app import and after every do_init phase (exports, type
tables, constructors, environment, runtime hooks, argv, and full-generation GC).

However, immediately after call_init returned through the Component Model boundary, before
component-init-transform measured globals or memory, the linear-memory fingerprints differed.
Disabling either or both WASI adapter/libc reset calls did not change that result. Ordering the
internal component-init-transform maps, reusing stable-inode directories, collecting Python
free lists after return through a second no-argument guest call, and retaining the Rust-level
app_name/Symbols values also did not fix it.

This localizes the remaining nondeterminism to the generated canonical-ABI post-return path for
the large nested init(app-name, symbols, stub-wasi) -> result<_, string> call (or allocator
state changed by that path), rather than Python initialization, component encoding, or snapshot
measurement. The current-main update moved from wit-bindgen 0.53.1 to 0.61.0 and Wasmtime 46.0.1
to 48.0.0; the exact responsible layer still needs a minimal reduction.

The experiment deliberately did not use post-generation byte rewriting or a volatile-byte
allowlist.

Proposed direction

1. Add a regression test that componentizes one fixture twice and compares the complete
   bytes.
2. Add an opt-in reproducible mode so existing build-time clock/random semantics do not
   change by default.
3. Give pre-initialization fixed clocks, random sources, Python hash seed, allocator state,
   and bytecode behavior in that mode.
4. Canonicalize generated directory metadata and provide input files through a staged or
   virtualized tree. The implementation should not modify user source-file metadata.
5. Keep output ordering deterministic throughout stub generation and component encoding.
6. Add a reduced test around the init canonical-ABI boundary. Candidate fixes include capturing
   memory before post-return cleanup, making that cleanup allocator-deterministic, or changing
   the private init protocol so the large nested argument graph does not leave volatile allocator
   state in the captured memory. Any fix must preserve matching allocator globals and memory.

Would the maintainers prefer this as one opt-in feature PR, or as smaller PRs after the
stub-ordering fix?

Additional context

This was found while building a digest-pinned Python/WASI runtime. Reproducibility is a
supply-chain requirement there: the generated component digest is part of the runtime
identity, not merely a build-cache optimization.

[dicej]

Thanks for reporting this. It looks like a duplicate of #243, which was also opened recently. Perhaps you and @composia-dave could collaborate on addressing this?

[dicej]

Your proposed plan sounds fine to me. A single large PR for this would be fine if that's easiest; otherwise items 3 and 4 in your "Proposed direction" list could be PR'd independently. #243 mentioned wasmtime-wasi changes may be needed, also; that issue has since been edited, so you'll need to look at the earlier revision of the PR description for details.

[starsang1995]

I dug into this a little further. It looks like the remaining differences come from host filesystem metadata entering CPython during import and surviving in memory captured by the snapshot. malloc_debug confirmed this, but it is too expensive and changes the allocator, so it does not seem like a good final fix.

I tried an alternative implementation here: reproducible component generation. It canonicalizes build-time filesystem metadata and clears transient interpreter state before snapshotting. It produces identical bytes across independent source copies while keeping CPython's default allocator, with no measurable performance impact in a small benchmark.

It is not as elegant as I would like because replacing the filesystem provider requires quite a bit of forwarding code, but it is the cleanest solution I have found so far without relying on allocator internals or rewriting snapshot memory.

[starsang1995]

Yeah @dicej more permanent and elegant fix would need to be done at wasmtime-wasi side.