> For the complete documentation index, see [llms.txt](https://argon-4.gitbook.io/argon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argon-4.gitbook.io/argon-docs/developers/verify-a-release.md).

# Verify a release

Confirm that the Enclave you installed is the Enclave in the repository: verify the signed tag, rebuild the release, and compare hashes.

Releases are built so that anyone can confirm the published extension corresponds exactly to a tagged, signed commit of the source. This takes three steps: verify the tag, rebuild, compare.

## 1. Verify the tag

Release tags are signed with SSH. The allowed signers are published in the repository, so verification needs no key server and no trust in a third party.

```bash
git clone <source repository> enclave
cd enclave
git -c gpg.format=ssh -c gpg.ssh.allowedSignersFile=docs/ALLOWED_SIGNERS tag -v v0.9.5
```

A good signature prints `Good "git" signature for ashton@onargon.com with ED25519 key …`. Anything else means the tag is not from the release signer; stop.

The configured publisher is `argonmining`; allowed signing keys are listed in `docs/ALLOWED_SIGNERS`. Public release policy requires that publisher's explicit approval through the protected release environment, a signed tag, full CI and verified build provenance. The private `0.9.5` beta does not claim public-release clearance or GitHub-attested provenance. See `docs/RELEASE_SECURITY.md` for the current controls and qualification requirements.

## 2. Rebuild

Check out the tag and run the release script from a clean tree with the pinned toolchain (see [Build from source](/argon-docs/developers/build.md) for prerequisites). The script refuses a dirty tree and a Node version other than the pinned one.

```bash
git checkout v0.9.5
scripts/release.sh
```

Archive and SBOM timestamps use the commit time (`SOURCE_DATE_EPOCH`), the zip is packed with sorted entries and no host metadata, and the software bill of materials is generated from the lockfiles. The result lands in `release/enclave-0.9.5-<commit>/`:

| Artifact                      | Contents                                                                                          |
| ----------------------------- | ------------------------------------------------------------------------------------------------- |
| `chrome-mv3/`                 | The unpacked extension matching the packaged zip                                                  |
| `enclave-0.9.5-chrome.zip`    | The extension package; building it does not submit it to the store                                |
| `enclave-0.9.5-source.tar.gz` | The tagged source snapshot                                                                        |
| `sbom/`                       | CycloneDX inventories for the shipped Rust WASM configuration and npm production dependency graph |
| `BUILD_METADATA.json`         | Source commit, dirty-tree status, toolchain versions and kernel build identity                    |
| `SHA256SUMS`                  | SHA-256 checksums for the files in the release directory                                          |

Run `shasum -a 256 -c SHA256SUMS` in the release directory to check the supplied files. Independently rebuild with the recorded toolchain and compare the resulting files. Identical output across different compilers or platforms must be demonstrated, not assumed. A signed tag and checksums establish different facts from build provenance; when a provenance bundle is supplied, verify its signer workflow, source tag and commit as described in `docs/RELEASE_SECURITY.md`.

## 3. Compare with what you installed

Chrome keeps the installed extension's files on disk. Find the extension's id on `chrome://extensions` (Developer mode shows it), then locate its directory:

| Platform | Path                                                                             |
| -------- | -------------------------------------------------------------------------------- |
| macOS    | `~/Library/Application Support/Google/Chrome/Default/Extensions/<id>/<version>/` |
| Windows  | `%LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\<id>\<version>\`      |
| Linux    | `~/.config/google-chrome/Default/Extensions/<id>/<version>/`                     |

Hash the installed files and compare with the `chrome-mv3/` entries in `SHA256SUMS`:

```bash
cd "<installed extension directory>"
find . -type f -print0 | sort -z | xargs -0 shasum -a 256
```

Two files may legitimately differ from the build: `manifest.json`, into which the Web Store injects a `key` and an `update_url`, and `_metadata/`, which the store adds. Everything else, including the kernel module `wasm/suresign_bg.wasm`, every script, and every stylesheet, must match exactly.

## What this proves

Matching installed files to an independently rebuilt signed source tag provides evidence that the installed package matches that build. Checksums alone detect changed files but do not authenticate the builder. Neither a successful rebuild nor signed provenance proves the code is correct; see [SureSign → Verification](/argon-docs/suresign/verification.md) for what is tested.

## Report a mismatch

A mismatch that is not one of the two expected files is serious. Do not use the installed extension. Report it privately as described under [Security](/argon-docs/developers/security.md), with the extension id, version, your `SHA256SUMS`, and the differing file's hash.