Glossary

Definitions for terms used across these docs. Where a term has its own dedicated explanation, the entry links to it.

Audit #

A signed statement, by one or more authors, about a specific package version identified by a subject tuple. An audit carries a short summary, a structured report, source-anchored annotations, findings, and machine-readable claims. See How it works for the role audits play in the wider lifecycle.

Auditor #

A capability granted to a key in a keyset, authorising it to sign audits.

Author #

The person or organisation who signs an audit. An audit can have one or more authors.

Capability #

A permission attached to a key in a keyset. The three capabilities are auditor (sign audits), publisher (add or modify audits in the log), and operator (modify the keyset). A single key can hold any combination.

Claim #

A boolean assertion about an observable property of audited code, drawn from a canonical vocabulary (impl-crypto, uses-unsafe, is-benign, and others) or defined as a custom claim by a consumer. See How it works for the role of claims in policy evaluation.

Commit #

A signed manifest recording one change to a log’s state, typically adding an audit or modifying the keyset. Commits are linked by a skipchain into the log and signed by a key from the log’s keyset.

Consumer #

A user (typically a project, team, or developer) running openvet check to gate dependencies against a policy. The consumer chooses which logs to subscribe to and which requirements to enforce.

Content addressing #

Referring to data by its cryptographic hash. OpenVet content-addresses commits, audits, and tree nodes, so tampering with any byte is detectable.

Custodial key #

A signing key generated and held by the registry on behalf of a user, enabling browser-based audit authoring without the user managing keys directly. See also self-custody and the Trust model for the broader tradeoff.

Generation #

A contiguous segment of a log. Routine work happens within a single generation; new generations are started only as a recovery mechanism for total operator-key loss.

Head #

The hash of the most recent commit in a log. The only mutable piece of state about a log; everything else is reachable from the head via content addressing.

Keyset #

The set of keys authorised to operate on a log, each carrying its own capabilities. The keyset is part of the log itself and is recorded and signed into the chain.

Log #

A per-entity append-only chain of commits. Holds an entity’s audits, keyset state, and the history of changes to both. Each log is owned by one log owner.

Log owner #

The entity (author or organisation) whose keys sign commits to a log. Trust in OpenVet attaches to logs, not to individual authors. See Trust model.

Mirror #

An alternative server serving the same content-addressed log bytes. Mirrors do not have to be trusted: the content addressing plus the owner’s signatures verify regardless of which mirror served the bytes.

openvet.lock #

A per-project lockfile pinning the verified head of each subscribed log plus the audits consumed. Committed alongside openvet.toml to keep openvet check deterministic across machines.

openvet.toml #

A per-project configuration file: which logs to subscribe to, which build-tool lockfiles to gate, and which requirements to enforce.

Operator #

A capability authorising modification of a log’s keyset. The most sensitive capability; typically held by a small number of carefully-managed keys.

Policy #

A consumer’s set of named requirements, declared in openvet.toml. Evaluated by the CLI against the audits found in subscribed logs.

Publisher #

A capability authorising modification of the log’s audit tree (adding, updating, or removing audits).

Registry #

A server hosting OpenVet logs. The public registry is openvet.org; the protocol is host-agnostic and any static host can serve a log.

Requirement #

A boolean expression over claim names, defined by a consumer. The unit of policy enforcement. See How it works for evaluation semantics.

Self-custody #

A key-custody posture in which the user holds their own signing keys; the registry holds nothing on their behalf. Contrast with custodial key.

Split-view #

An attack in which a server serves different log heads to different consumers. Detectable to consumers who fetch from multiple hosts. Not possible at all in self-custody mode, where the server has no signing keys and can only withhold commits rather than forge divergent histories.

Subject #

The identifier of a package version that an audit covers. The subject tuple shape is (registry, name, version, variant, hash); the hash pins the exact bytes of the package.

Transitive trust #

A trust model in which trust flows through a graph: A trusts B, B trusts C, so A trusts C. Used by PGP’s web of trust and by crev. OpenVet rejects transitivity; trust attaches only to logs the consumer has explicitly subscribed to.

Variant #

A field of the subject tuple that distinguishes flavours of the same package version when a registry supports them.

Web of trust #

A trust model in which users sign trust proofs for other users, computing effective trust by traversing the resulting graph. Used by PGP and crev. OpenVet rejects this model in favour of explicit per-log subscription; see cargo-crev.