0.34.0

Added — prikk trust maintainer list and check: asking what a repository trusts

Until now there was no way to ask which MAINTAINER keys a repository currently trusts — a caller
had to attempt a seal and see whether it failed. prikk trust maintainer list [--format json]
enumerates every currently adopted key, in adoption order; prikk trust maintainer check --key-id <ID> [--format json] answers whether one specific id is adopted. Both read a policy already
loaded on every seal; neither adds any new state, and neither changes adoption, revocation, or
what seal requires.

check exits 0 whichever way the question resolves. "Key X is not trusted" is a successful
answer, not an operational failure — exiting 1 for a negative answer would file a successful
query as a refusal, the exact conflation a machine-readable exit code exists to avoid. 1 and 2
keep their usual meanings: an unreadable policy is 1, a missing or malformed --key-id is 2.

Changed — trust maintainer add and setup print a derived count, not a literal

Both used to print policy: required=1 after adopting a key — a literal, from a policy that has
no such field (MaintainerTrustPolicy holds a Vec and nothing else; trust is any-of-N by
construction). They now print adopted maintainer keys: <n>, where <n> is read back from the
policy and changes as more keys are adopted. prikk trust maintainer list already states what
trust means; this line's job is only to say how many.

Prebuilt binaries

Linux (aarch64/x86_64), Windows (x86_64), macOS (aarch64). Each archive contains the prikk binary, LICENSE, and a sibling .sha256
checksum plus .build-info.txt recording the exact toolchain and command used to build
it — reproduce with:

git checkout <tag> && cargo build -p prikk --release --target <triple> --locked

cargo install prikk remains the toolchain-based install path; these binaries are an
additional option, not a replacement.

macOS binaries are unsigned. Gatekeeper will warn on first run — right-click (or Control-click) the binary and choose Open, or clear the quarantine attribute directly with xattr -d com.apple.quarantine <path>. Notarization needs an Apple Developer identity and is a stated gap for a future increment, not an oversight.

Release authority — read before relying on this release

This release does not pass the DC-35 signer-authority audit, and does not claim to. The
committed release-signer set (release-signers.toml) is empty and fail-closed, so no release
currently satisfies that gate. A checksum published beside a binary on this page proves integrity of
transport, not authority of origin. Verify what you obtain by content, not by release authority —
see prikk verify and this project's
release-compatibility reference.