Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Parity Attestation

Attestation is what separates Vrtmv from a package-renaming script. Every migration produces evidence that an auditor can rely on.

The attestation report

vrtmv migrate writes, alongside the Ansible role, a vrtmv-attestation.json. It records:

  • the source and target releases;
  • the depersonalized VM fingerprint and the anchors it was derived from (audit transparency);
  • each translated canonical, its target packages, and its graded confidence;
  • packages that resolved to no canonical, and canonicals with no translation to the target;
  • manual runbook steps and caveats from conditionals that fired or could not be evaluated;
  • config-path relocations that need operator attention.

Because conditionals are evaluated locally against the real inventory, the report is specific to the host that produced it — not a generic mapping.

Honesty over completeness

The report distinguishes clearly between what Vrtmv translated, what it could not, and what it could not determine. An unevaluable predicate becomes a caveat, not an assumption. A canonical with no vetted translation is reported as untranslated rather than guessed. Silence — the absence of a row — is treated as a truthful “nothing to report”, not a gap to paper over.

This discipline is deliberate: a fabricated mapping that looks authoritative is worse than an acknowledged gap, because an auditor may rely on it.

Fingerprints

The VM fingerprint is a one-way hash derived from stable host anchors (such as machine-id, fstab, and boot UUIDs). It lets Vrtmv recognise the same VM across runs — for metering and for linking a maintenance re-scan to its initial migration — without carrying any host identity off the machine.

Signing

When the service has signing enabled, vrtmv migrate also writes vrtmv-attestation.sig.json — a cryptographic signature over the report, produced by Vrtmv’s own key rather than a self-signed operator key.

The engine keeps workload data local: it sends only the report’s SHA-256 digest and the OS pair to the API, which signs a compact envelope binding that digest to the authenticated account, the moment, and Vrtmv’s key id. The signature file carries the signature, the exact bytes it covers, and a how_to_verify note. Vrtmv’s public key is published, unauthenticated, at /v1/attest/pubkey.

An audit firm verifies in two steps: recompute the SHA-256 of vrtmv-attestation.json and confirm it matches the digest in the signed envelope; then verify the Ed25519 signature against the published public key. What this attests is provenance — that a Vrtmv-authenticated account produced this exact report at this time, signed by Vrtmv — and it is tamper-evident: any later edit to the report changes its digest and breaks verification.