md2.3 KB

Provenance Verification Runbook (Markdown)

The five checks a verifier must perform against the attestation fixtures in this category, and the exact result each one should produce — including the two that are meant to fail. Every package, version, hash and licence is fictional — the tree describes nothing real.

Editor testing Conversion testing

Preview — first 43 linesmd

# Provenance verification runbook (SAMPLE)

> Signatures, key ids and certificates here are SAMPLE placeholders — the base64 decodes to the words 'SAMPLE SIGNATURE', so verification must fail. Nothing here is cryptographically valid and no key material is real.

Every file referenced below is in this category. Nothing here verifies successfully by design — the point is to exercise the failure path as well as the happy one.

## 1. Locate the attestation

Start from the artifact digest, not from a filename. The release artifact is `orchard-gateway-4.2.0.tgz` with sha256 `06af88e316cf889e0b72645f235f77c900d48972456b1ff6ba4df49ae24be734`. That digest appears as:

- the `subject[0].digest.sha256` of the in-toto statements,
- the `payloadHash` of the Rekor entry,
- the first line of `SHA256SUMS.txt`.

If those three disagree, stop: the attestation does not describe the artifact you have.

## 2. Unwrap the envelope

`dsse-envelope.json` carries the statement as base64 in `payload`. Decode it and check it byte-matches `in-toto-slsa-provenance-v1.json`. The bad-payload fixture in this family is the negative case: it must fail here, not later.

## 3. Check the builder

`predicate.runDetails.builder.id` must equal `https://build.orchard.example/builders/hosted/v1`, which is the only entry in the allowed list in `attestation-policy.yaml`. A provenance statement that verifies cryptographically but names an unexpected builder is still a policy failure.

## 4. Check transparency-log inclusion

`sigstore-bundle.json` and `rekor-log-entry.json` both carry an inclusion proof with a root hash and a tree size of 51201. Recompute the proof — do not trust the `signedEntryTimestamp` alone.

## 5. Apply the policy

`slsa-verification-summary.json` says PASSED at SLSA_BUILD_LEVEL_3. The dependency breakdown in `slsa-level-matrix.csv` shows two dependencies still at level 0, which the policy refuses — a green top-level result does not clear the tree beneath it.

## Expected outcome with these fixtures

| Step | Result |
| --- | --- |
| Digest agreement | passes |
| Payload decode | passes (fails for the bad-payload fixture) |
| Signature verification | **fails** — SAMPLE placeholder |
| Builder identity | passes |
| Log inclusion | passes structurally |
| Policy evaluation | **blocks** — two dependencies at level 0 |

Specifications

Seed: 51200
Sample Only: true
Format: Markdown
Steps: 5
Expected Outcomes: 6
Line Endings: LF

Testing contract

Reference control

Scenario: Use a documented expected-outcome table to test a verifier end to end.
Expected result: A correct verifier reproduces all six rows: four passes, a signature failure and a policy block.

What is a .md file?

Markdown (MD) is a lightweight plain-text markup language that uses simple punctuation conventions to denote headings, lists, links, emphasis, and code. It is designed to be readable as-is and to convert cleanly to HTML. It is widely used for documentation, READMEs, and content authoring.

How to use this file

Use an example Markdown file to test parsers and renderers, verify GitHub-Flavored Markdown extensions like tables and fenced code, and exercise HTML-conversion pipelines.

How to use this file for testing

“Provenance Verification Runbook (Markdown)” is a deterministic Novus Examples fixture for Editor testing, Conversion testing. Text-based files you can open, edit, and download directly in the browser editor.

Documented properties for this file: seed 51200 · LF · Markdown. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.

Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.

SBOM, lockfile, provenance, and advisory fixtures describe the same fabricated component tree across formats, so a converter or scanner can be diffed against a known answer. Every package name, version, hash, and advisory ID is invented — never treat a finding here as real.

Code examples

import markdown  # pip install markdown

html = markdown.markdown(open("provenance-verification-runbook.md").read())
print(html[:200])

Generated by generation/supply_chain.py. Free for any use, no attribution required — license.