verifyeventcli

package
v0.23.0 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Jun 12, 2026 License: Apache-2.0 Imports: 16 Imported by: 0

Documentation

Overview

Package verifyeventcli implements the `agent-receipts verify-event` subcommand: end-to-end pipeline-provenance evidence for a single historical receipt. Where `verify` answers "is this chain internally consistent?", verify-event answers the narrower question that matters most for trust: "was this specific receipt produced by the path ADR-0010 describes — emitter → daemon → chain — as opposed to being written to SQLite by some other path?"

It composes the existing chain checks (signature, hash linkage, sequence contiguity — #479) with the daemon-captured peer credential (#511) that ADR-0010 § Permissions and trust calls the load-bearing evidence: the agent's self-asserted identity is untrusted; peer attestation is what makes the audit meaningful. verify-event is the verifier-side counterpart that actually uses that field.

Deliberately narrow scope: it does NOT attest that the audited action happened in the world (no protocol can), nor that the emitter binary is trustworthy beyond its exe_path matching an operator allowlist. Binary integrity attestation is a separate, ADR-grade decision.

The store is opened read-only so verify-event is safe to run against a live daemon's database or a forensic snapshot, and it never emits — unlike `doctor`'s synthetic round-trip, this is a cheap historical read.

Logic lives here, away from cmd/agent-receipts/main.go, so tests can drive the subcommand directly with captured I/O without shelling out to a binary.

Index

Constants

View Source
const (
	ExitOK           = 0 // verified AND pipeline-provenance confirmed
	ExitVerifyFailed = 1 // a check failed — the receipt is suspect, investigate
	ExitUsageError   = 2 // bad flags / unreadable DB or key / no receipt selected
	ExitNoProvenance = 3 // verifies cryptographically but lacks peer-credential evidence
)

Exit codes are part of the CLI contract — CI gates and triage scripts pivot on them. Keep these stable.

ExitNoProvenance (3) is the distinction the Max incident exposed and the reason this subcommand exists: a receipt can verify cryptographically yet carry no evidence that it traversed the documented pipeline. A CI gate that requires provenance treats 3 as a failure; one that only requires cryptographic validity treats 0 and 3 alike. Splitting them into separate codes is what lets operators choose.

Variables

This section is empty.

Functions

func Run

func Run(args []string, stdout, stderr io.Writer, envLookup func(string) string) int

Run executes the verify-event subcommand with the given args (sans the program name and "verify-event" token), writing human-readable output to stdout and diagnostics to stderr. Returns one of the Exit* constants.

envLookup is split out so tests can inject a deterministic environment. Pass os.Getenv for the production caller.

Types

This section is empty.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL