Repository navigation
perf: verify documents in the preload with Web Crypto instead of JS SHA-256 - #322
Merged
Merged
Conversation
…HA-256 The preload checks every document it receives against its envelope hash. The validators are synchronous and the sandboxed preload has no node:crypto, so the check ran a plain-JavaScript SHA-256: ~200 ms of renderer time for the 8 MB bench document, on every open. Validators now run with the hash checks collected (collectDigestClaims); the preload awaits them through crypto.subtle.digest (verifyDigestClaims) before handing the payload on. Same checks, same verdict, and outside that call isNotoDocumentWire still hashes synchronously. Deliveries that can carry a document go through one arrival-ordered chain, so a later event is never handed on before an earlier document. Renderer-thread preload check on huge ~258 -> ~52 ms; packaged Linux open ~1.65 -> ~1.49 s (interleaved).
…igest # Conflicts: # docs/performance/measurements.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The preload still verifies every document it receives against the envelope hash. The integrity check is unchanged; what changed is how the hash is computed.
node:crypto, and Web Crypto only answers with a promise. So the check used to run a plain-JS SHA-256 on the renderer thread.collectDigestClaims(run)runs any validator with the envelope-hash checks collected instead of computed. Every other check runs as before.verifyDigestClaims(claims)then checks each claim withcrypto.subtle.digest('SHA-256'), falling back to the portablesha256Hexif Web Crypto is missing. A payload passes only if the validator passes and every claim verifies, which is the same verdict as the synchronous path. No document validator branches on the hash result: unions are discriminated bystatus/ exact keys, so collecting can't change which branch accepts.collectDigestClaims,isNotoDocumentWirestill hashes synchronously. Tests and any other caller are unchanged.invoke,invokeFileTruth,invokeWorkspaceandsubscribehand payloads on through one arrival-ordered chain. A later event is never delivered before an earlier document, whether or not it carries one itself.Measured (huge 8 MB, packaged, Linux box, interleaved with
f25d1fe)compressSha256Block~201)BENCH_RUNS=5Tests
preload-native-digest.test.ts:node:crypto) on empty input, every padding boundary (55–128 bytes), CJK + emoji + lone-surrogate text, a BOM, and 3 MB of random bytes.pnpm typecheckandpnpm testpass.