Verify the log without trusting us

What you are checking and why

You are checking that the public record of tool-description fingerprints has not been quietly rewritten. If the signatures and proofs check out, the published history matches the signed tree heads. You do not need to trust this website’s HTML to do that.

The fastest way

If you already have the plumb command installed, run this against the published static bundle (JSON files under /log/):

plumb verify-log --bundle ./site/log --pubkey ./site/log/pubkey.txt

Local path shown by default. With JavaScript enabled, this updates to the URL of the site you are viewing.

A passing result (exit code 0, line result OK) means the checkpoint signatures and consistency proofs checked out for this bundle, and any inclusion proofs that were sampled also checked out. It means the published history was not rewritten relative to the signed tree heads. It does not mean the tools themselves are safe.

Install

Pre-built binary releases are not published yet (signed releases are blocked until CI signing is restored). The current install route is go install, which needs a Go toolchain (1.23 or newer).

macOS: Install Go from https://go.dev/dl/ (or brew install go), then run go install github.com/GautamTalksDev/Plumbline/cmd/plumb@latest. Ensure $(go env GOPATH)/bin is on your PATH.
Linux: Install Go from your distribution or https://go.dev/dl/, then the same go install .../cmd/plumb@latest command. Put $(go env GOPATH)/bin on your PATH.
Windows: Install Go from https://go.dev/dl/, open a new terminal, run go install github.com/GautamTalksDev/Plumbline/cmd/plumb@latest, and add the Go bin directory (usually %USERPROFILE%\go\bin) to your user PATH.

You also need the published public key. Download /log/pubkey.txt, or use the in-repo file docs/log-public-key.ed25519. They must match.

What the output means

Typical output from plumb verify-log --bundle:

Line	What it checks	What a pass shows	What a failure means
`checkpoint`	Ed25519 signature on each published checkpoint	Tree heads were signed with the published key	Wrong key, or a checkpoint was altered
`consistency`	Proofs between consecutive checkpoints	Later trees still contain earlier ones	History may have been rewritten between checkpoints
`inclusion`	A sample of inclusion proofs against the signed root	Sampled entries are in the signed tree (for example `true (500 of 3355 proofs checked)`)	A named index failed; the bundle or root may be wrong
`inclusion skipped (...)`	Whether proofs were available to check	Honest skip: `0 proofs found` or `no proof index` over HTTP	Not a cryptographic fail by itself; inclusion was not evaluated
`leaf_hashes`	Whether leaf fingerprints were evaluated (via inclusion on the bundle path)	`true` after a successful inclusion sample	`skipped (not evaluated)` if inclusion never ran; `false` if a checked leaf did not bind to the root
`result`	Overall verdict	`OK`, exit code 0	`FAIL`, exit code 1; error lines name the failing checkpoint or index

Exit code 2 means an operational problem (bad flags, network error), not a cryptographic verdict.

What this does not prove

That the crawler observed every server correctly, or at all
That any server or package is safe to run
That the severity taxonomy is complete or correctly applied
That absence of published findings means absence of drift

Optional: live HTTP API

If a conforming log HTTP API is available, the same CLI accepts --url and can re-hash leaves from entry payloads. See docs/VERIFY.md.

Independent of this page

HTML and JavaScript here are convenience only. Anyone can mirror the /log/ JSON and run plumb verify-log --bundle against that mirror.