sandbox: a manifest is pinned only when its image AND every feature are digest-addressed #270

Merged

dcharlot merged 1 commit from fix/manifest-pinned-means-pinned into main 2026-10-15 22:35:42 -04:00

Conversation 0 Commits 1 Files changed 4 +76 -12

dcharlot commented 2026-10-15 20:50:58 -04:00

Owner

Copy link

What was wrong

EnvironmentManifest::is_pinned() checked only the base image's digest, but its doc promised "fully pinned" and "same address ⇒ same bytes". Its own test asserted it true for a manifest whose features were rust:1 and node:1.

Those are tags. A tag resolves to whatever its publisher last pushed under it, so two hosts can run different toolchains under one manifest address.

The spec made the same overclaim. It called such a manifest pinned, which made it fit for a cross-host "same environment" claim, exactly what unpinned manifests are kept out of.

The fix

• Feature::is_pinned(): the feature reference carries an @sha256: digest.
• EnvironmentManifest::is_pinned(): the image and every feature are digest-addressed. image_pinned() is the old image-only check.
• What pinned means: the docs, spec/environment-manifest.md and SPEC §14 now say it means the whole toolchain. Mounted content is data and never part of the address, so a pinned manifest says nothing about what its mounts hold.
• C7 conformance now checks three things:
  • the image is digest-addressed, as its label always said;
  • a feature declared by tag leaves the manifest unpinned;
  • digest-addressed features pin it.

Pinned-ness is not part of the manifest core, so no content address or vector changes.

Checked

Run on the build host:

• sandbox-attest: 50 tests pass, including the new pinned_means_every_feature_is_digest_addressed.
• sandbox-conformance: all classes pass, including C7.
• Clippy reports nothing new. Its two warnings, in fleet.rs and vectors.rs, predate this change.

Putting is_pinned() back to the image-only check fails 2 unit tests and C7 ("a feature declared by tag leaves the manifest unpinned").

🤖 Generated with Claude Code

## What was wrong `EnvironmentManifest::is_pinned()` checked only the base image's digest, but its doc promised "fully pinned" and "same address ⇒ same bytes". Its own test asserted it true for a manifest whose features were `rust:1` and `node:1`. Those are tags. A tag resolves to whatever its publisher last pushed under it, so two hosts can run different toolchains under one manifest address. The spec made the same overclaim. It called such a manifest **pinned**, which made it fit for a cross-host "same environment" claim, exactly what unpinned manifests are kept out of. ## The fix - **`Feature::is_pinned()`:** the feature reference carries an `@sha256:` digest. - **`EnvironmentManifest::is_pinned()`:** the image and every feature are digest-addressed. `image_pinned()` is the old image-only check. - **What pinned means:** the docs, `spec/environment-manifest.md` and SPEC §14 now say it means the whole toolchain. Mounted content is data and never part of the address, so a pinned manifest says nothing about what its mounts hold. - **C7 conformance** now checks three things: - the image is digest-addressed, as its label always said; - a feature declared by tag leaves the manifest unpinned; - digest-addressed features pin it. Pinned-ness is not part of the manifest core, so no content address or vector changes. ## Checked Run on the build host: - `sandbox-attest`: 50 tests pass, including the new `pinned_means_every_feature_is_digest_addressed`. - `sandbox-conformance`: all classes pass, including C7. - Clippy reports nothing new. Its two warnings, in `fleet.rs` and `vectors.rs`, predate this change. Putting `is_pinned()` back to the image-only check fails 2 unit tests and C7 ("a feature declared by tag leaves the manifest unpinned"). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-15 20:50:58 -04:00

sandbox: a manifest is pinned only when its image AND every feature are digest-addressed ... d79332b061

`EnvironmentManifest::is_pinned()` checked the base image's digest alone,
while its doc promised "fully pinned" and "same address ⇒ same bytes". Its
own test asserted it true for a manifest whose features were `rust:1` and
`node:1`. Those are tags, which resolve to whatever was last pushed under
them, so two hosts can run different toolchains under one address. The
spec repeated the overclaim: it called such a manifest pinned, and so fit
for a cross-host "same environment" claim.

- `Feature::is_pinned()`: the reference carries an `@sha256:` digest.
- `EnvironmentManifest::is_pinned()`: the image and every feature are
  digest-addressed. `image_pinned()` is the old image-only check.
- Its docs, the spec (spec/environment-manifest.md, SPEC §14): pinned means
  the whole toolchain. Mounted content is data and never part of the
  address, so a pinned manifest says nothing about what its mounts hold.
- C7 conformance checks the image (as it always said it did), that a
  feature by tag leaves the manifest unpinned, and that digest features pin
  it.

Pinned-ness is not in the manifest core, so no content address or vector
changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request 2026-10-15 22:35:17 -04:00

jcp-energy: the RAPL probe tests advance their fake zones on the probe's own tick #272

dcharlot referenced this pull request from a commit 2026-10-15 22:35:18 -04:00

jcp-energy: the RAPL probe tests advance their fake zones on the probe's own tick

dcharlot merged commit 490d641675 into main 2026-10-15 22:35:42 -04:00

dcharlot referenced this pull request from a commit 2026-10-15 22:35:43 -04:00

Merge pull request 'sandbox: a manifest is pinned only when its image AND every feature are digest-addressed' (#270) from fix/manifest-pinned-means-pinned into main

dcharlot referenced this pull request from a commit 2026-10-15 23:16:39 -04:00

Merge remote-tracking branch 'origin/main' into wai/d2c-m5

dcharlot referenced this pull request 2026-10-15 23:16:43 -04:00

D2c M5: wai.neural.int_mlicpp decodes through wai-ops/1 (wmb1/1), goldens unchanged; the direct guard leaves production #273

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!270

No description provided.