Verification

Prove that what you downloaded is exactly what was built — and that it hasn't been tampered with.

Trust the pinned key, not the release

Every Clearcote release is checksummed and GPG-signed against a single, out-of-band pinned key. Verification means: import the key, confirm its fingerprint equals the pinned value below, then check the signature. Never trust whatever key is merely attached to a release.

Verify a download

From the folder where you downloaded the release assets:

# 1. inspect the public key and CONFIRM the fingerprint matches the pinned value above
gpg --with-fingerprint --show-keys clearcote-signing-key.asc

# 2. import it
gpg --import clearcote-signing-key.asc

# 3. verify the signed checksum file  (expect: Good signature)
gpg --verify SHA256SUMS.txt.asc SHA256SUMS.txt

# 4. verify the archive's checksum     (expect: OK)
sha256sum -c clearcote-149.0.7827.114-windows-x64.zip.sha256

# 5. (optional) confirm the inner binary matches SHA256SUMS.txt
unzip -p clearcote-149.0.7827.114-windows-x64.zip chrome.exe | sha256sum

A "this key is not certified with a trusted signature" warning on step 3 is expected — it just means you haven't personally web-of-trust-signed the key. The proof is the fingerprint match plus the Good signature, not a trust marker.

On Windows (PowerShell)

If you don't have GnuPG handy, you can at least check the archive hash:

(Get-FileHash .\clearcote-149.0.7827.114-windows-x64.zip -Algorithm SHA256).Hash.ToLower()
# must equal the zip line in SHA256SUMS.txt

Reproducibility

Beyond signatures, the build itself is auditable: a pinned upstream revision, a readable patch set, and a public config/args.gn. Chromium cross-builds are not yet bit-for-bit deterministic, so the guarantee today is “every change is an auditable patch and the config is public” — full hash-match attestation is on the roadmap. See docs/VERIFY.md for the canonical, version-pinned steps.