Artifacts & Proofs

Everything Pollis ships publicly (desktop app, terminal client, verifier), with the transparency-log proof that the bytes you download are the bytes we published.

Everything below is fetched on load from our verification API, and every verdict is computed by the server. Your browser checks one thing: that the served signing key matches the key pinned in this page. To check the rest yourself, run the 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 a verdict that doesn't depend on trusting us.

New to this? Learn: reading this page explains what a root is, what an inclusion tick means, and what a green badge does not prove.

Latest releases

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

Loading desktop release…

Loading release proofs…

Loading CLI release…

pollis-verify (auditor CLI) build from source

Re-checks everything on this page against the one pinned key, without trusting our server. Prebuilt Linux and macOS binaries (with .sha256 files) ship on the pollis-verify-* releases, but building from source is better: a verifier we hand you is one we could have tampered with. The licence is PolyForm Noncommercial 1.0.0. That is source-available, not OSI open source; it 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 append-only Merkle logs: the commit log (conversation history), account keys (published identity keys) and binaries (release hashes). A scheduled job re-audits all three daily and republishes their signed tree heads, which let anyone holding the pinned log key check that each log is append-only and unforked. This section only displays the current heads; it cannot prove consistency in your browser. The verification docs and the transparency-publish workflow / run logs show how to check it yourself.

Loading signed tree heads…

The one key you trust

Every signature above, on every tree head and every release, is checked against one pinned public key. It is an ML-DSA-44 (post-quantum) key, so signed statements about history stay checkable long after they were made (#668). It is new key material: the earlier Ed25519 key and its seed were retired, not re-encoded.

PINNED LOG PUBLIC KEY

Checking served key against the pinned constant…

This is the only check your browser performs: it compares the key the server serves, character by character, with the constant in this page. If the constant were missing, the page would say no check ran rather than imply a match. Every other verdict here is computed by the server; re-run it with pollis-verify to check it yourself.

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. These checks trust no Pollis key at all. Every release artifact also carries a keyless cosign signature and a SLSA build-provenance attestation, both recorded in Sigstore's public Rekor log, which Pollis does not operate and cannot retract from. The signing identity is the release workflow, so a signature asserts "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. releases/latest/ holds installers only, with no signature, certificate or attestation, so verification against it cannot work.

BASE=https://cdn.pollis.com/releases/v1.17.4 ART=pollis-v1.17.4-windows.exe REPO=pollis-app/pollis # the signer: actuallydan/pollis up to v1.17.2 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. REPO is the repository that built the tag: the project moved from actuallydan/pollis to pollis-app/pollis after v1.17.2, and a release's certificate names the repository it was built in.

2 · VERIFY THE COSIGN SIGNATURE

cosign verify-blob \ --certificate-identity-regexp "^https://github\.com/$REPO/\.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. Don't drop the identity pattern: without it cosign accepts a signature from any Sigstore identity. cosign 3.x prints a deprecation notice for --signature and --certificate; the check still passes.

3 · VERIFY THE SLSA BUILD PROVENANCE

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

4 · READ THE DEPENDENCY LIST (SBOM)

Each release publishes a CycloneDX SBOM at $BASE/pollis-<tag>.cdx.json, built from Cargo.lock and pnpm-lock.yaml at the tagged commit. It is a provenance subject, so its digest is in Rekor with the installers and a later replacement would be detectable. Verify it like any other artifact, then read it:

curl -sSL "$BASE/pollis-v1.17.4.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: these bytes came from that workflow, at that tag, in that repository, and the record sits in a public log Pollis does not control. They do not prove the bytes reproduce from source (that is the separate rebuild check, which covers the Linux AppImage only), and they do not prove the source was good. A workflow building bad source produces a valid attestation.

GitHub Actions is inside the trust boundary, as the whitepaper states. Anyone who can alter the release workflow, or GitHub itself, can mint a signature that verifies. This anchor takes Pollis's key out of the trust path, not GitHub.

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

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

What these proofs do and don't say:

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

The transparency logs prove that commit history, published keys and binaries were not forked, rolled back or shown differently to different people, trusting only the pinned log key. They do not prove the server behaves correctly in real time, and they provide no anonymity.

The Delivery Service is a hosted service, not a download, so it isn't listed here. Its /version endpoint reports the git SHA of the running build.