Module provision 

How a fetched daemon release is proven (BIND-18): which checks, in what order, and which failures stop the fetch.

The policy is fetch_release, written against two ports: ReleaseSource for the release’s files and AttestationVerifier for the Sigstore check. microvms-edges implements both (reqwest against GitHub, sigstore-verify with its embedded trusted root) and owns the cache and the file writes around them. Here, the order is the whole point:

1. Download the asset.
2. Fetch an attestation bundle for its digest. When one arrives, it must verify against Signer::release for the requested tag, or the fetch stops: the bytes are discarded and nothing else is tried. Falling through to the checksum here would launder bytes that failed provenance into a weaker check that can’t see what was wrong with them.
3. When the release answers that it publishes no bundle for these bytes (Bundles::Absent), the fetch stops the same way. Every release that ships SHA256SUMS (v0.5.0 on) also ships its bundle, so a missing one never means an older release: it means the asset isn’t the one the release workflow built. Someone who can edit a release’s assets but can’t run its workflow would otherwise delete the bundle, upload their own asset with a matching SHA256SUMS, and pass as checksum.
4. Only when no answer can be had at all (Bundles::Unreachable: a transport failure, a rate limit, a server error), check the bytes against the release’s SHA256SUMS. A release with no SHA256SUMS (every tag before v0.5.0) fails closed rather than trusting TLS alone.

That’s the table crates/model/src/provision.rs checks, with “a bundle arrived, or the release answered that it has none” where it says “gh downloaded”. Verification tells the caller which proof it got.

Structs

Fetched

The asset’s bytes, and how they were proven.

Signer

Who must have signed a release’s attestation, and what it must attest.

Enums

Bundles

What a lookup of the attestation bundles for one digest found. Each reason is prose; the policy adds what it means.

Verification

How a fetched binary’s bytes were proven.

Constants

ACTIONS_ISSUER

The OIDC issuer of a GitHub Actions workflow identity.

ASSET

The release asset’s name: a literal, because the README’s --pattern agentd and the checksum lookup both match it exactly.

CHECKSUMS

The release asset listing every other asset’s SHA-256, in sha256sum’s format.

RELEASE_REPO

The repository whose releases carry the daemon asset.

RELEASE_WORKFLOW

The workflow that builds and attests the release, relative to the repository root.

SLSA_PROVENANCE_V1

The in-toto predicate type actions/attest-build-provenance writes, and the one gh attestation verify requires by default.

Traits

AttestationVerifier

The Sigstore check over one bundle.

ReleaseSource

Where a release’s files come from. The error is prose; the policy adds what it means.

Functions

fetch_release

Release tag’s ASSET, proven by attestation or, when no answer about its bundle can be had, by checksum. See the module docs for the order and why it’s that order.

sha256_hex

The lowercase hex SHA-256 of bytes.

verify_sha256

Checks bytes against asset’s entry in a SHA256SUMS body (<64 hex> <name> per line, sha256sum’s own format). In-process, because sha256sum the tool doesn’t exist on Windows.