openvet-policy

Requirement language and evaluator for OpenVet. Turns a project's TOML-defined policy and the audits collected for a single subject into a pass or fail verdict with structured per- requirement diagnostics.

The wire format and evaluator semantics are specified in detail in the policy specification. this README covers the high-level idea and the practical surface.

Requirements, claims, expressions

A claim is a (name, bool) pair emitted by an audit (e.g., memory-unsafe-code: true). OpenVet's canonical claim vocabulary — defined in the vocabulary specification — is deliberately atomic: each claim is an observable property of the code (does the package contain memory-unsafe code? does it open network listeners? was the unsafe code specifically reviewed?) rather than a context-sensitive judgement like cargo-vet's safe-to-deploy.

A requirement is a boolean expression over claim names that the consumer wants to hold for every dependency — (not memory-unsafe-code) or reviewed-unsafe, for example. The evaluator runs each requirement's expression against every audit's claims and then collapses across audits into a single verdict.

Expressions support and, or, not, and parentheses with standard precedence. Claim names are [a-zA-Z_][a-zA-Z0-9_-]*.

TOML shape

# Bare form: default-on requirement, value is the expression.
[requirement]
safe-to-deploy = """
  (not memory-unsafe-code or reviewed-unsafe) and
  (not has-crypto or reviewed-crypto) and
  (not io-network-listener)
"""

# Table form: opt-in by overriding into the requirement set.
[requirement.fuzz-tested]
condition = "has-fuzz-tests"
default = false

# Per-subject overrides. Matcher fields are AND'd; "*" / omitted = wildcard.
[[override]]
registry = "cargo"
package = "libc"
requirements = { add = ["fuzz-tested"], remove = ["safe-to-deploy"] }

[[override]]
package = "serde"
requirements = ["safe-to-deploy"]   # replace form

# Cross-log claim renames: "log:claim" → canonical name.
[alias]
reviewed-unsafe = ["mozilla:audited-unsafe", "google:unsafe-verified"]

Overrides and aliases

The effective requirement set for a subject is computed by walking the [[override]] blocks in declaration order: each override whose matcher matches the subject either replaces the working set or patches it, depending on whether requirements is a plain list (replace) or an { add = [...], remove = [...] } table (patch).

Aliases let a consumer treat differently-named claims from different logs as the same canonical claim. They apply at claim-lookup time — an audit from a log not listed under an alias falls through to the canonical name unchanged.

Evaluation

Three-valued Kleene logic per audit (True, False, Unknown) with standard short-circuiting: False short-circuits and, True short-circuits or, and not Unknown == Unknown. The Unknown branch is load-bearing — an audit can perfectly well not have an opinion on has-crypto, and that is not the same as actively asserting has-crypto: false.

A requirement passes for a subject iff at least one audit returns True and no audit returns False. Fail variants distinguish nobody had enough info (NotAsserted) from an audit explicitly disagrees (Contradicted); the latter carries a snapshot of the relevant claims so the failure message can show why.

A subject passes iff all of its effective requirements pass.

Users

This crate is used by the openvet command-line tool.