Layer 2026.09.15 still ingests -linux-gnu for every Linux payload — ordeal, synth and meld already publish static musl (the #175 decision's layer half is not implemented)

[avrabe]

What was measured

The 2026.09.15 rolling layer (issued 2026-09-25T00:56Z, ghcr.io/pulseengine/layers:2026.09.15). I decoded the signed DSSE payload and read each Linux payload's eu.pulseengine.source.asset annotation. Every Linux payload was ingested from a -linux-gnu asset. This holds even for tools whose release already publishes a static musl build:

tool	release	musl assets published	what the layer ingested
ordeal	v0.21.0	x86_64 + aarch64 -unknown-linux-musl (static-pie, no PT_INTERP, zero DT_NEEDED)	ordeal-v0.21.0-{x86_64,aarch64}-unknown-linux-gnu.tar.gz
synth	v0.74.0	2	synth-v0.74.0-{x86_64,aarch64}-unknown-linux-gnu.tar.gz
meld	v0.58.3	2	meld-v0.58.3-{x86_64,aarch64}-unknown-linux-gnu.tar.gz
rivet, spar, witness, loom, kiln, sigil, varve	latest	0	gnu (no musl asset to take yet)

In ordeal's case the musl assets are inside the cosign-signed SHA256SUMS.txt, the same proof the gnu assets use. That means proof = cosign-sums covers them unchanged.

Why this is an open item and not done

The decision comment on #175 (2026-09-24) says: "The layer ingests the musl asset for its Linux platform keys." #175 was then closed as done. The closing evidence was varve's own release.yml gaining musl legs. The layer-ingestion half of the decision is not implemented. A consumer installing 2026.09.15 on RHEL 9, Debian 12, Amazon Linux 2023, Alpine or distroless-static still gets the GLIBC_2.39-floored binaries #175 measured. That is true even for the three tools that already ship a binary which would run there.

Also noticed while reading the payload: loom has no aarch64-unknown-linux-gnu payload in 2026.09.15. It has 3 platforms where every other tool has 4.

Ask

• For each Linux platform key, ingest the tool's -unknown-linux-musl asset when the release publishes one (today: ordeal, synth, meld). Fall back to gnu otherwise. plan.rs already has the asset-for override used for wac/wrpc. A per-tool musl preference, or a realm-level "prefer musl" rule, would express this without guessing names.
• Record which libc each Linux payload carries, so the layer states its portability floor instead of implying one. For example, add an annotation next to eu.pulseengine.platform.
• Reopen Linux releases are glibc-only (2.39 floor) — ship musl builds too #175 or link it here, so the "layer switches to musl" decision has an open tracker until the layer actually does.
• (separate, small) the missing loom aarch64-linux payload.

Evidence reproducible anonymously: fetch the manifest for tag 2026.09.15, download the first layer blob (DSSE envelope), base64-decode payload, and list manifests[].annotations.

Refs: #175 (decision), pulseengine/ordeal#143 (ordeal's musl legs, shipped v0.20.0).

[avrabe]

Still reproduces on 2026.09.16 (created 2026-09-25T11:55Z): its Linux payloads for ordeal 0.22.0 and rivet 0.39.0 are ingested from ordeal-v0.22.0-{x86_64,aarch64}-unknown-linux-gnu.tar.gz / rivet-v0.39.0-…-linux-gnu.tar.gz. ordeal v0.22.0 publishes both static musl archives inside its cosign-signed sums, same as 0.21.0.

[avrabe]

Scoped into #202 — v0.40.0 The layer tells the truth, where it is listed with what it is and why it belongs to that release.

Closed to make the board a plan rather than a pile: the epic is the release, and its checklist is the scope. Nothing here is dropped or downgraded — reopen this issue if it needs its own thread again.