Don't trust us. Verify.

Reproducible build and integrity.

The 22 tests above run inside your browser. The bundle that runs them is delivered from this server. If a sophisticated attacker compromises the delivery path, the tests still pass, but they pass on whatever JavaScript the attacker injected, not on the published source. The countermeasure is: pin the bundle to known-good hashes, and reproduce the build from public source.

What's served right now.

Every cryptographic asset on deny.sh has a published Subresource Integrity (SRI) hash. These are the SHA-384 digests of the exact bytes our server is sending you. Recompute them locally, paste them into your integrity attribute, and your browser will refuse to execute any byte that doesn't match. This table is generated from the live manifest; for an authoritative, self-running check, use Proof D — Asset integrity self-check above, which hashes the served bytes in your browser and compares them to the manifest.

Recompute any of these locally with one command:

# pin verify.js by recomputing its hash and comparing
curl -sf https://deny.sh/js/verify.js?v=75 \
  | openssl dgst -sha384 -binary \
  | base64

# compare against the table above. mismatch = do not trust the bundle.

A live SRI manifest, machine-readable, is published at /.well-known/integrity.json and updated on every deploy. Pin against that if you're integrating deny.sh assets into another origin.

Reproduce the build.

From the open beta onward, the published artefact (the JS bundle that powers the in-browser verifier and the SDK on npm) is built from a tagged commit on deny-sh-crypto/deny-js with a single deterministic command. Same source + same Node version + same dependency lockfile = byte-identical output. If your build doesn't match the published SRI hash, either the source changed or someone tampered with the artefact.

# 1. clone the public source at the released tag
git clone https://github.com/deny-sh-crypto/deny-js
cd deny-js
git checkout v2.3.1

# 2. pin Node and reinstall from lockfile (no transitive surprises)
nvm use 22.22.2
npm ci

# 3. build the published bundle
npm run build:web

# 4. hash the bundled crypto.js the same way the server does
cat dist/web/crypto.js | openssl dgst -sha384 -binary | base64

# expect: OLz8xZ6aeZasfCql1pvERSZ2ijXb5SEFl+T4AMRoANaKVeMWym2Xc5IHfaV1IQ7w

Determinism details. The build pins Node v22.22.2 (LTS), uses npm ci against a committed package-lock.json, and disables timestamp-based dependency invalidation. The bundler (esbuild v0.25 in --minify --no-bundle-time-comment mode) writes byte-deterministic output for the same input. We don't ship sourcemap timestamps, build hostnames, or compile-time strings into the bundle.

How publishing and signing work.

Every release of the SDK lands on three independent surfaces, each with its own integrity story:

• npm registry. npm publish from a workstation that holds the publishing token. npm computes its own SHA-512 integrity field and stores it in the package metadata. npm install deny-sh@2.3.1 --integrity verifies on install. The published package.json includes the repository.url pointing at the public source mirror, so you can diff what npm shipped against what GitHub holds.
• GitHub release. Tagged commit + signed annotated tag. The release page on deny-sh-crypto/deny-js/releases publishes the source tarball + a SHA256SUMS file + the maintainer's GPG signature over that file. Verify with gpg --verify SHA256SUMS.sig SHA256SUMS.
• This server. The web bundle is rebuilt from the tagged commit and uploaded to the deny.sh origin behind Cloudflare. The SRI manifest at /.well-known/integrity.json is regenerated on every deploy. If the bundle changes without a corresponding GitHub tag and signed release, that's a tamper signal.

Coordinated disclosure for any integrity issue (mismatched hash, unsigned release, source-vs-published divergence) goes to security@deny.sh per the disclosure policy.

Honest caveat. Reproducible builds protect against tampering between source and your browser. They don't protect against bugs in the source itself; that's what the in-browser test suite, the cross-language byte-compatibility KAT vectors in the four SDKs, the cryptographic construction write-up, and the external cryptographic audit on the roadmap are for. Different layers of defence; check all of them.