← Back to Pollis

Artifacts & Proofs

Every public thing Pollis ships (desktop app, terminal client, verifier) and the append-only transparency-log proof that the bytes you download are the exact bytes we published.

This page is a live demonstration. Everything below is fetched fresh on load from our server-computed verification API, the browser here verifies nothing except one local string comparison (the pinned signing key). You don't have to take our word for any of it: re-run the exact same checks yourself with our pollis-verify command-line tool (source-available; see the FAQ on licensing), or query the public verification API directly (rate limits apply). Only the CLI gives you a trustless verdict.

New to any of this? Learn: reading this page is the legend for the map, what a root is, what an inclusion tick actually means, and what green here does not prove.

Latest releases

The current version of each public output and where to get it. For the desktop app, the table shows every shipped installer and whether its bytes are provably committed to the public binaries transparency log.

Loading desktop release…

Loading release proofs…

Loading CLI release…

pollis-verify (auditor CLI) build from source

This is the tool auditors run to independently re-check everything on this page, trusting only the one pinned key, with no server on the path. Prebuilt Linux and macOS binaries (with .sha256 files) ship on the pollis-verify-* releases, but building it from the public repo is the stronger move, since a verifier we hand you is a verifier we could have tampered with. The source is readable and buildable by anyone; the licence is PolyForm Noncommercial 1.0.0, which is source-available rather than OSI open source, and that limits what you may ship — not what you may audit.

cargo build -p verifiable-log-serve --bin pollis-verify produces ./target/debug/pollis-verify

Source & README Verification docs

Daily transparency self-audit

Pollis publishes three separate append-only Merkle logs: the commit log (conversation history), account keys (published identity keys), and binaries (shipped release hashes). A scheduled job re-audits all three every day and republishes their signed tree heads. Those signed heads are what prove each log is append-only and fork-free (no rollback, no equivocation) trusting only the one pinned log key. This displays the current published heads; it does not, and cannot, prove consistency in your browser, the verification docs and the transparency-publish workflow / run logs show how to check that yourself.

Loading signed tree heads…

The one key you trust

All of the above trusts exactly one thing: a single pinned public key. Every signature, on every tree head, on every release, is checked against it. If you trust this key, you can verify everything; if you don't, verify nothing. It is an ML-DSA-44 post-quantum key, so a signed statement about history stays meaningful for as long as anyone might want to re-check the past (#668). The key below is fresh material: the earlier Ed25519 key, and the seed it was derived from, were retired outright rather than re-encoded.

PINNED LOG PUBLIC KEY

Checking served key against the pinned constant…

That comparison is the only verification your browser ever performs: it fetches the key the server serves and compares it, character by character, to the constant baked into this page. If the constant were ever absent the browser would perform no verification at all, and would say so rather than imply a match. Everything else on this page is a server-computed verdict, re-run it with pollis-verify to make it trustless.

WHAT AN AUDITOR RUNS

pollis-verify remote https://verify.pollis.com re-audit all three whole logs over HTTP
pollis-verify release https://verify.pollis.com <tag> verify one release's shipped binaries are in the log
pollis-verify group https://verify.pollis.com <conversation_id> verify one conversation's commit history is fork-free
pollis-verify account https://verify.pollis.com <user_id> verify one user's published key history

VERIFICATION API

Base: https://verify.pollis.com. Example read endpoints anyone can fetch: /v1/sth/latest.json, /v1/binaries/sth/latest.json, and /verify/release/<tag>.

The second anchor: Sigstore, SLSA and the SBOM

Everything above trusts one Pollis-held key. This section trusts none. Every release artifact also carries a keyless cosign signature and a SLSA build-provenance attestation, both anchored in Sigstore's public Rekor transparency log — which Pollis does not operate, cannot write to selectively, and cannot retract from. There is no Pollis key anywhere in these checks. The signing identity is the release workflow itself, so what a signature asserts is "this file came out of desktop-release.yml at this tag", not "someone at Pollis approved this".

1 · FETCH THE ARTIFACT AND ITS EVIDENCE

Use the version-pinned path. The releases/latest/ shortcut carries the installers only — no signature, certificate or attestation is published under it — so a verification recipe written against latest cannot work.

BASE=https://cdn.pollis.com/releases/v1.9.7 ART=pollis-v1.9.7-windows.exe curl -sSLO "$BASE/$ART" # the artifact curl -sSLO "$BASE/$ART.sig" # cosign detached signature curl -sSLO "$BASE/$ART.pem" # cosign signing certificate curl -sSLO "$BASE/$ART.intoto.jsonl" # SLSA build-provenance attestation Substitute any released tag and any of -macos.dmg, -windows.exe, -linux.AppImage, -linux.deb, -linux.rpm.

2 · VERIFY THE COSIGN SIGNATURE

cosign verify-blob \ --certificate-identity-regexp '^https://github\.com/actuallydan/pollis/\.github/workflows/desktop-release\.yml@refs/tags/v.*$' \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ --signature "$ART.sig" \ --certificate "$ART.pem" \ "$ART" Prints Verified OK. The identity pattern is the point: without it, cosign would accept a signature from any Sigstore identity, which proves nothing. cosign 3.x also prints a deprecation notice for --signature and --certificate; the check still runs and still passes.

3 · VERIFY THE SLSA BUILD PROVENANCE

gh attestation verify "$ART" \ --bundle "$ART.intoto.jsonl" \ --repo actuallydan/pollis \ --cert-identity-regex '^https://github\.com/actuallydan/pollis/\.github/workflows/desktop-release\.yml@refs/tags/v.*$' \ --cert-oidc-issuer https://token.actions.githubusercontent.com Prints ✓ Verification succeeded! and names the build workflow and tag. Exit status 0 is the verdict — gh prints the banner only to a terminal, so in a script check the status, not the output. The flag is --cert-identity-regex, with no trailing "p".
slsa-verifier verify-artifact "$ART" \ --provenance-path "$ART.intoto.jsonl" \ --source-uri github.com/actuallydan/pollis \ --source-tag v1.9.7 The same check with a standalone verifier, if you would rather not trust GitHub's own CLI to grade GitHub's own attestation.

4 · READ THE DEPENDENCY LIST (SBOM)

Each release publishes a CycloneDX software bill of materials at $BASE/pollis-<tag>.cdx.json, catalogued from Cargo.lock and pnpm-lock.yaml at the tagged commit. It is also a provenance subject, so its digest is recorded in Rekor alongside the installers — a quieter SBOM published later cannot replace it without the substitution being provable. Verify it exactly like any other artifact, then read it:

curl -sSL "$BASE/pollis-v1.9.7.cdx.json" | jq '.components | length' SBOMs begin at the first release after 16 August 2026; earlier tags have no .cdx.json and the URL returns 404. See the limits below.

Where this guarantee ends:

cosign and SLSA prove build provenance — that these exact bytes were produced by that workflow, at that tag, in that repository, and that the record is in a public log Pollis does not control. They do not prove the bytes reproduce from source; that is the separate rebuild check, and it covers the Linux AppImage only. They also do not prove the source was good: a workflow faithfully building bad source produces a perfectly valid attestation.

GitHub Actions is inside the trust boundary here, and the whitepaper says so. The signing identity is a workflow running on GitHub's infrastructure, so anyone able to alter that workflow, or GitHub itself, can mint a signature that verifies. This anchor removes Pollis's key from the trust path; it does not remove GitHub from it.

Provenance is not a release gate, and two early releases shipped without it. Signatures and attestations are retained on the CDN indefinitely, but installers older than the last three releases are pruned — for those, GitHub Releases remains the permanent archive.

The SBOM lists what the lockfiles resolved to, not what the linker actually consumed. Vendored C and C++ compiled inside build scripts — notably webrtc-sys and webrtc-audio-processing-sys — is not catalogued. It is also not yet a leaf in the binaries transparency log.

What these proofs do and don't say, precisely:

The binaries log and payload hashes prove the published bytes match and are committed to a public append-only log. That is not a claim that every platform is byte-for-byte reproducible from source. Linux payload reproduction is documented (reproducible-builds-residuals.md); macOS and Windows are published-bytes-match only.

The transparency logs prove no fork, no rollback, no equivocation of commit history and published keys and binaries, trusting only the one pinned log key, nothing more. They do not prove the server behaves correctly in real time, and they are not anonymity.

The Delivery Service exposes no build or version endpoint by design (metadata minimization), so it isn't listed here. The browser on this page verifies nothing but the local pinned-key string match; treat every other verdict as server-computed until you re-check it with the CLI.