v0.30.0: two live defects a five-way review found, and the gates that stop them returning

.github/workflows/ci.yml

@@ -158,6 +158,25 @@ jobs:
           VARVE_CORROSION_TEST: "1"
         run: cargo test -p varve-core --test corrosion_offline -- --nocapture
 
+  keydisk:
+    name: no signing key on disk (REQ-NOKEYDISK-001)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
+      # `docs ci` names `echo "$SECRET" > key.tmp` as the thing adopters
+      # wrongly invent, and `docs root-ceremony` says the key must reach varve
+      # through a file descriptor. This repository's own deposit workflow wrote
+      # it to a predictable /tmp path on a shared runner for every layer it
+      # published, and an assessor found that by reading the repo rather than
+      # the docs. A rule the publisher does not follow is not evidence, so the
+      # rule is mechanical from here.
+      # Prove the gate can go red BEFORE trusting it green -- the controls
+      # include the exact line this repository shipped.
+      - name: Negative control — the gate must reject what it exists to reject
+        run: tools/no-key-on-disk.sh --self-test
+      - name: Refuse a workflow that writes key material to a file
+        run: tools/no-key-on-disk.sh
+
   mutants:
     name: cargo mutants (trust-critical gate)
     runs-on: ubuntu-latest
@@ -217,8 +236,12 @@ jobs:
             -f crates/varve-core/src/layerspec.rs \
             -f crates/varve-producer/src/asset.rs \
             -f crates/varve-producer/src/attestation.rs \
+            -f crates/varve-producer/src/binfmt.rs \
+            -f crates/varve-producer/src/carryforward.rs \
+            -f crates/varve-producer/src/extract.rs \
             -f crates/varve-producer/src/forge.rs \
             -f crates/varve-producer/src/ingest.rs \
+            -f crates/varve-producer/src/plan.rs \
             -f crates/varve-producer/src/spec.rs \
             -f crates/varve-producer/src/sums.rs
 

.github/workflows/deposit-layer.yml

@@ -77,18 +77,25 @@ jobs:
           VARVE_ROLLING_KEY: ${{ secrets.VARVE_ROLLING_KEY }}
           LAYER: ${{ inputs.layer }}
           COUNTER: ${{ inputs.counter }}
+        shell: bash
         run: |
           set -euo pipefail
           test -n "$VARVE_ROLLING_KEY" || { echo "::error::VARVE_ROLLING_KEY not provisioned"; exit 1; }
-          printf '%s' "$VARVE_ROLLING_KEY" > /tmp/rolling.key
+          # The key reaches varve through a FILE DESCRIPTOR, never a file
+          # (REQ-NOKEYDISK-001). `docs ci` documents this form and names
+          # `echo "$SECRET" > key.tmp` as the thing adopters wrongly invent --
+          # and this workflow did exactly that, to a predictable path, on a
+          # shared runner, for every deposit. An assessor found it by reading
+          # the repository rather than the documentation, which is the way
+          # this class of finding is always found.
           ISSUED_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
           # The spec and the payload bytes it points at live together under
           # deposit-stage/ — a payload `path` resolves relative to the SPEC
           # FILE's directory, so the staging area moves as one tree.
           ./target/release/varve deposit \
             --spec deposit-stage/deposit-spec.toml \
             --issued-at "$ISSUED_AT" \
-            --key /tmp/rolling.key --key-id varve-rolling-1 \
+            --key <(printf '%s' "$VARVE_ROLLING_KEY") --key-id varve-rolling-1 \
             --out layer-layout
           # Sign and attach a BASELINE line-status (REQ-STATUS-DIST-001) so
           # `varve status` works after an offline OR registry install with no
@@ -100,11 +107,10 @@ jobs:
             "$LINE" "$COUNTER" "$ISSUED_AT" > baseline-status.json
           ./target/release/varve sign-status \
             --file baseline-status.json \
-            --key /tmp/rolling.key --key-id varve-rolling-1 \
+            --key <(printf '%s' "$VARVE_ROLLING_KEY") --key-id varve-rolling-1 \
             --out baseline-status.dsse.json
           ./target/release/varve attach-status \
             --layout layer-layout --status baseline-status.dsse.json
-          rm -f /tmp/rolling.key
           # Sanity: the deposit installs and verifies on THIS runner before
           # anything is published.
           mkdir -p sanity-project

.github/workflows/release.yml

@@ -327,6 +327,9 @@ jobs:
         env:
           VARVE_ROOT_KEY: ${{ secrets.VARVE_ROOT_KEY }}
           VARVE_ROLLING_KEY: ${{ secrets.VARVE_ROLLING_KEY }}
+        # Explicit, because the key reaches varve by process substitution and
+        # that is a bash feature, not a POSIX one.
+        shell: bash
         run: |
           set -euo pipefail
           if [ -n "${VARVE_ROOT_KEY:-}" ]; then
@@ -344,16 +347,16 @@ jobs:
             exit 0
           fi
           cargo build --release -p varve
-          printf '%s' "$SIGNING_KEY" > /tmp/varve-root.key
+          # File descriptor, never a file (REQ-NOKEYDISK-001) -- see the same
+          # correction in deposit-layer.yml.
           cd release-assets
           # The signing code is the same sign_release_sums the verifier
           # tests against — producer and consumer cannot drift.
           ../target/release/varve sign-sums \
             --sums SHA256SUMS.txt \
-            --key /tmp/varve-root.key \
+            --key <(printf '%s' "$SIGNING_KEY") \
             --key-id "$KEY_ID" \
             --out SHA256SUMS.txt.dsse.json
-          rm -f /tmp/varve-root.key
           ls -la SHA256SUMS.txt.dsse.json
 
       - name: Capture build environment

.github/workflows/systest.yml

@@ -153,3 +153,16 @@ jobs:
         # It ends by rebuilding varve with the pin's choice deleted from the
         # one place it is consulted, and requires the run to go red.
         run: tools/systest/compose-realms.sh "$RUNNER_TEMP/compose-realms"
+
+  install-shadow:
+    name: the installer names which varve will run (REQ-INSTALLSHADOW-001)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
+      # A maintainer followed the documented install and ended up running a
+      # DIFFERENT binary than the one it installed, because being on PATH is
+      # not being first on it. varve refuses to claim success when PATH
+      # shadows a pinned tool; this holds its own installer to that standard.
+      # The gate carries its own negative control.
+      - name: Installer must warn when another varve wins PATH
+        run: tools/systest/install-shadow.sh