feat(gha): use released mip to fetch pkgs artifacts for CI - #692

.github/workflows/ci-macos.yml (1)

46-54: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Stale comment: job no longer builds the minimal CLI to materialize artifacts.

With this change, materializing the kernel/rootfs (Lines 79-92) is now done by fetching a prebuilt mip via the composite action, not by building minimal from source. The remaining toolchain/cargo-cache steps are for cross-compiling minimald into the initramfs (Line 97), not for the materialize step. Worth updating the comment so it doesn't mislead future readers about what's actually happening here.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci-macos.yml around lines 46 - 54, Update the stale
explanatory comment in the CI macOS workflow so it matches the current flow: the
kernel/rootfs materialization is no longer done by building the `minimal` CLI
from this repo, but by fetching a prebuilt `mip` through the composite action.
Keep the comment focused on the actual steps around the materialize job and the
later `minimald` cross-compilation/initramfs cache steps, and remove references
to building `minimal` or repo-source artifact generation.

.github/actions/materialize/action.yml (4)

71-73: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

fetch() has no request timeout.

--retry 3 only retries failed connections; it doesn't bound a stalled/slow transfer. A hung download would block the step until the job-level timeout-minutes kills it.

⏱️ Suggested fix

 fetch() {
-  curl --proto '=https' --proto-redir '=https' --tlsv1.2 --retry 3 -fsSL "$1" -o "$2"
+  curl --proto '=https' --proto-redir '=https' --tlsv1.2 --retry 3 \
+       --connect-timeout 10 --max-time 120 -fsSL "$1" -o "$2"
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/actions/materialize/action.yml around lines 71 - 73, The fetch()
helper currently relies on curl retries but has no request timeout, so a stalled
download can hang the action step. Update fetch() in the materialize action to
add an explicit curl timeout option (for both connect and overall transfer)
while keeping the existing HTTPS-only and retry behavior, so the download fails
fast instead of waiting for the job timeout.

---

83-88: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

INPUT_CHANNEL isn't restricted to an allowlist before being interpolated into the fetch URL.

arch is validated with a case statement (Lines 49-52), but channel flows straight into "$BASE/$INPUT_CHANNEL" unchecked. All current callers pass hardcoded literals (stable/unstable), so this isn't exploitable today, but as a reusable action it's worth constraining for defense-in-depth.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/actions/materialize/action.yml around lines 83 - 88, Validate
INPUT_CHANNEL in the action before it is used in fetch and only allow the
expected literals (for example, stable and unstable), similar to the existing
arch case check. Update the version-resolution block in materialize/action.yml
so the "$BASE/$INPUT_CHANNEL" URL is only constructed after the allowlist check,
and fail early with a clear error if the channel is anything else.

---

90-98: 🔒 Security & Privacy | 🔵 Trivial | 🏗️ Heavy lift

No integrity verification of the downloaded mip binary before execution.

The script fetches mip over TLS and immediately chmod +x + executes it (Line 98) with no checksum/signature check against the resolved version. TLS protects transport, but not against a compromised/tampered object in the bucket. Other fetch scripts in this repo are described elsewhere as "pin-verified" (e.g. gvproxy fetch) — this new path departs from that pattern for a binary that gets executed directly.

🔒 Suggested approach

Publish a checksum (e.g. sha256) alongside each mip-linux-$runner_arch build and verify it after fetch:

         bin="$RUNNER_TEMP/mip"
         fetch "$BASE/versions/$version/mip-linux-$runner_arch" "$bin"
+        fetch "$BASE/versions/$version/mip-linux-$runner_arch.sha256" "$bin.sha256"
+        (cd "$RUNNER_TEMP" && sha256sum -c <(awk '{print $1, "mip"}' mip.sha256))
         chmod +x "$bin"

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/actions/materialize/action.yml around lines 90 - 98, The `mip`
download-and-execute path in the action script is missing integrity verification
before running the binary. Update the fetch flow around the `fetch`, `chmod +x`,
and `materialize` steps to verify the downloaded `mip-linux-$runner_arch`
artifact against a checksum or signature tied to the resolved `version` before
execution. Use the existing `version`/`runner_arch` resolution in this action to
locate the right verification data, and only proceed to `"$bin" materialize`
after the verification succeeds.

---

83-93: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Every materialize call re-resolves the channel and re-downloads mip, even within the same job.

release.yml's fetch-release-guest-artifacts job invokes this action 4 times back-to-back; ci-macos.yml/ci-linux-kvm.yml invoke it twice each. Each call re-fetches the channel pointer and the mip binary from scratch, since nothing persists resolution across steps in the same job ($RUNNER_TEMP is per-job, but the script never checks for an existing/matching binary before fetching again).

♻️ Suggested optimization

+        if [[ -x "$bin" ]] && [[ "$(cat "$RUNNER_TEMP/.mip-version" 2>/dev/null)" == "$version" ]]; then
+          echo "Reusing already-fetched mip $version"
+        else
+          fetch "$BASE/versions/$version/mip-linux-$runner_arch" "$bin"
+          chmod +x "$bin"
+          echo "$version" > "$RUNNER_TEMP/.mip-version"
+        fi

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/actions/materialize/action.yml around lines 83 - 93, The materialize
action always re-resolves the channel and re-downloads mip on every invocation,
even when the same job has already resolved the same channel/version. Update the
action logic around the channel-pointer resolution and mip download to first
check for an existing cached/matching binary in the job temp area before calling
fetch again, and only re-fetch when the channel or version has changed. Keep the
behavior localized to the existing resolve-and-download flow using the
channel-pointer, version, and bin steps.