Inspect the code. Verify.

Source and download 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. Compare against an independently obtained trusted fingerprint, and check the available source and release evidence.

What's served right now.

The manifest lists file fingerprints for supported assets. Subresource Integrity (SRI) lets a browser compare a script or stylesheet with an expected fingerprint. 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. A mismatch needs investigation: source, dependencies, tooling and build configuration can all change the output.

# 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.

Check the available evidence on each release surface:

• 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. Check the release for its commit, tag and signing status. The release page on deny-sh-crypto/deny-js/releases may provide source archives and a SHA256SUMS file. Where a GPG signature is published, verify it with gpg --verify SHA256SUMS.sig SHA256SUMS.
• This server. Compare the web bundle on the deny.sh origin with the relevant published source and release artefacts. The SRI manifest at /.well-known/integrity.json is regenerated on every deploy. A difference requires investigation; check which assets, commits and release artefacts are being compared.

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.