VIRP demo evidence bundle — session-20260801T073527Z
=====================================================

Produced by demo/run.sh from a fresh clone of public main at commit 1794eed,
on an independent verifier machine, 2026-08-01 07:35 UTC. 9/9 behaviors
observed. Clone to pass: 15 seconds, measured on that machine.

THE TARGET WAS SIMULATED. The demo uses the built-in mock driver, so this
bundle evidences protocol behavior: what was classified, what executed or was
refused, what was authenticated, and what a verifier accepts or rejects. It
does not evidence that any real device was reached or reported truthfully.

KEYS IN THIS BUNDLE ARE DISPOSABLE AND DELIBERATELY PUBLISHED
-------------------------------------------------------------
run/onode.key  (32 bytes)  the collector's HMAC key
run/chain.key  (32 bytes)  the chain HMAC key
run/approval.pub (32 bytes) the approver's Ed25519 PUBLIC key

They are published so anyone can recompute every authentication tag and
replay the chain independently. They were generated for this one run, exist
nowhere else, and protect nothing. In a deployment the collector's key is
secret, and that secrecy is exactly what makes a valid tag evidence rather
than decoration.

ONE FILE WAS REMOVED FROM THE PUBLISHED COPY
--------------------------------------------
run/approval.key, the approver's Ed25519 SECRET key, is NOT included.
Verifying an approval signature requires only the public half, so publishing
the secret would expose material no verifier needs. Its absence changes
nothing you can check.

That asymmetry is the point of the project's terminology: observations are
"authenticated" (symmetric HMAC; verifying requires the same secret that
produces it, so every holder must be trusted), while approvals are "signed"
(Ed25519; anyone can verify with the public key alone). This bundle
demonstrates both, and demonstrates why only one of them let us withhold
the secret.

Original archive as delivered by the verifier (including approval.key):
  sha256 0d17287cda399eb06bad9e5461aec3634e1fc1f8cfc66332585a9c9ad85c9dff

A NOTE ON THE WORD "signed" IN THESE RECORDS
---------------------------------------------
records/01-green.txt prints "obs_type=0x07 (signed observation)" and
"signature=VALID". That is the reference tool's own output, reproduced here
byte for byte. This site says "authenticated" for HMAC material and reserves
"signed" for Ed25519, and the tool has not yet been updated to match. The
records are published unedited because falsifying evidence to match our
preferred vocabulary would be far worse than the inconsistency. Renaming the
CLI output is tracked as a code-level item.

WHAT IS HERE
------------
SUMMARY.txt        the harness's own pass/fail record, stamped with the commit
records/           per-step outputs, one file per demonstrated behavior
records/03-*.bin   an observation and the same observation with ONE byte changed
onode.log          the collector daemon's log for the whole session
devices.json       the simulated target definition
run/chain.db       the SQLite evidence chain (6 entries, 2 sessions)
run/approvals/     the proposal, challenge, approval, and consumed-list records

VERIFY IT YOURSELF
------------------
  # replay the chain
  ./build/virp-tool chain tail --db run/chain.db

  # verify the intact observation, then the tampered one (which must fail)
  ./build/virp-tool inspect records/03-observation.bin          run/onode.key okey
  ./build/virp-tool inspect records/03-observation-tampered.bin run/onode.key okey

  # or produce your own bundle from scratch
  git clone https://github.com/nhowardtli/virp && cd virp
  docker compose -f demo/docker-compose.yml run --rm demo

The chain in this bundle was independently re-verified before publication by
recomputing each entry hash as SHA-256 over its canonical JSON and walking
every per-session link from that session's genesis
(SHA-256("VIRP_CHAIN_GENESIS:" + session_id)). All six entries verify.