Verify this build

Keymaker runs entirely in your browser, which means whoever served you this page is the trust anchor. Reading the source on GitHub tells you nothing about the JavaScript that arrived here. That is true of every web app and it matters more here, because this one is asked to hold seed phrases.

This page will not tell you it has verified itself. It cannot: everything on it came from the same place as the code you are questioning. What it can do is tell you exactly what this build claims to be, and give you the commands that check the claim from outside.

What this build claims

Application version: 2.2.0
Container format: KEYM v3
Source commit: ac46309cead3509fbb410b8794417a777c12cf0b

That commit is also baked into every asset path under _next/static/, so it is not a label that can be changed without changing the build. It is still a claim — the checks below are what turn it into a fact.

1. Are these the files CI produced?

Every deployment publishes a SHA256SUMS manifest and a Sigstore bundle signing it. Mirror the site and check the files against the manifest:

# Fetch the manifest, then exactly the files it names.
mkdir -p site && cd site
BASE=https://404secnotfound.github.io/Keymaker-v2
curl -fsSL -o SHA256SUMS          "$BASE/SHA256SUMS"
curl -fsSL -o SHA256SUMS.sigstore "$BASE/SHA256SUMS.sigstore"
sed 's/^[0-9a-f]\{64\}  //' SHA256SUMS |
  while IFS= read -r path; do
    curl -fsSL --create-dirs -o "$path" "$BASE/$path"
  done

sha256sum -c SHA256SUMS

sha256sum is on every Unix machine and has nothing to do with this project, which is the point: that step needs no software you have to trust us about.

The app can tell you which manifest it is running against. In the container inspector, open the footer line sealed · runs in this tab and press Check now: it hashes the files its service worker holds against the manifest cached beside them and prints that manifest’s sha256 — read back from the cache, not from this page. The number should equal sha256sum SHA256SUMS on your mirror. It proves the running set is consistent, not who made it; the commands here are what settle that.

2. Who signed that manifest?

With cosign:

cosign verify-blob \
  --bundle SHA256SUMS.sigstore \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity 'https://github.com/404SecNotFound/Keymaker-v2/.github/workflows/deploy.yml@refs/heads/main' \
  SHA256SUMS

Keyless signing, so there is no published key to obtain and no key distribution to get wrong. The check is not “signed by a key we told you about” — it is signed by this workflow, in this repository, and --certificate-identity is the flag that makes it so. Without that flag cosign verify-blob accepts a signature from anybody and still prints Verified OK.

Get that identity from somewhere other than this page. It is the one value the whole check rests on, and it reached you from the origin you are checking. Sigstore signing is open to any GitHub repository, so a tampered copy of this page can name its own workflow, sign its own manifest with it, and every command here will genuinely pass. Read the string out of docs/VERIFYING.md in the repository, or skip it entirely and run node scripts/verify-manifest.mjs from a clone — that script carries the identity in its own source and takes nothing from the site under test.

3. Does that artifact match the source?

The first two checks prove GitHub built something and served it to you intact. They say nothing about whether that something matches the code you can read. The build is reproducible — two clean builds of one commit produce identical bytes, and CI enforces it on every change — so you can settle that yourself by rebuilding ac46309cead3 and diffing the manifests.

The full procedure, including what these checks do not prove, is in docs/VERIFYING.md. The commands above are generated from that document at build time rather than copied beside it, so the two cannot drift.

What none of this proves

Not the identity in that command. A hostile origin serves a hostile page, and the certificate identity printed above is the trust root of the entire procedure. Substituting it is not forgery and does not fail any check — the attacker’s signature over the attacker’s manifest is real, and cosign will say so. This is not something a better page could fix; a page cannot establish its own provenance. It is why the string has to come from the repository rather than from here.
Not that the code is correct. Verification says the bytes you ran match the source in the repository. Whether that source is any good is what the audit, the test suites and the independent Python implementation are for.
Not that the repository is honest. Anyone who can push to main gets a valid signature over whatever they built. What catches that is the history being public and the diff reviewable.
Not your machine. A browser extension, a compromised device or a hostile TLS path after you verified are all outside what a signature can reach.
Not this page. If the bundle were replaced, this page would be replaced with it — and a tampered copy would happily print reassuring text. Run the commands; do not take the page’s word for anything.

Your encrypted files do not depend on any of this. A .keym container is decryptable with reference/keym2.py and no browser at all — a copy ships with this app, under /recovery/.