Allow reproducible builds with javy.#1151
Allow reproducible builds with javy.#1151saulecabrera merged 8 commits intobytecodealliance:mainfrom
Conversation
saulecabrera
left a comment
saulecabrera
left a comment
There was a problem hiding this comment.
Changes look reasonable to me, but in general maybe we could consider integrating https://github.com/Shopify/deterministic-wasi-ctx, instead? The motivation of that crate is the same as what you're describing in your PR, modulo it covers several other sources of non-determinism e.g., random.
Adds `deterministic` option to the test runner Builder and an integration test that verifies two separate deterministic builds of the same JS source produce byte-identical WASM output.
saulecabrera
left a comment
saulecabrera
left a comment
There was a problem hiding this comment.
I think this is moving in the right direction. I think we should still fix the comments around dependencies and duplication.
Nice, I'll try replacing mine with this. I'm glad I read this because I was about to open another draft with a few small changes to plug into more places that I didn't see before. |
…Shopify/deterministic-wasi-ctx The `with_determinism` helper only fixed wall and monotonic clocks but left `secure_random` and `insecure_random` using per-context random state. During Wizer pre-initialization the QuickJS runtime calls WASI random (e.g. for hash seeds), causing the memory snapshot to differ across runs. - Replace both secure and insecure random with constant zero-filled deterministic sources when deterministic mode is enabled - Disable parallel compilation and enable NaN canonicalization for the Wasmtime Engine in deterministic mode - Add `test_deterministic_init_plugin` test - Update CHANGELOG and all flag docs with security note about random sources being non-secure when determinism is active Made-with: Cursor
saulecabrera
left a comment
saulecabrera
left a comment
There was a problem hiding this comment.
I think this is close, thanks for your patience iterating on this.
| @@ -0,0 +1,150 @@ | |||
| // Exercises many runtime code paths during Wizer pre-initialization to stress | |||
| // parallel compilation ordering and NaN canonicalization in Cranelift. | |||
There was a problem hiding this comment.
See my comment in with_deterministic_engine
|
Also, it seems that CI is failing with compilation errors https://github.com/bytecodealliance/javy/actions/runs/22958007777/job/66803827504?pr=1151 |
Same, thanks for your patience as well. I wish I knew Rust and the details of the WASM compilation better. Lmk if the reasoning that Claude provided on why we need the engine flags makes sense or not. |
saulecabrera
force-pushed
the
rtinianov_reproducible_builds
branch
from
7b8f646 to
d73ef48
Compare
saulecabrera
force-pushed
the
rtinianov_reproducible_builds
branch
from
d73ef48 to
4e6e31e
Compare
Invokes init-plugin --deterministic twice on the same uninitialized plugin and asserts byte-identical output, then verifies the resulting plugin is functional. Made-with: Cursor
My pleasure, any chance you can tag it and cut a release for the crate today? |
2 participants
Description of the change
Allow reproducible builds with javy via a flag
Why am I making this change?
Our customers need to prove their binary image ran. We have signatures on the binary that ran, alongside the data it produced.
Checklist
javy-plugin-apiif the QuickJS bytecode has changed.javy-cli,javy-plugin, andjavy-plugin-processingdo not require updating CHANGELOG files.