aqua resolves wasm-pack macos-arm64 to the x86_64 asset, so the pinned attestation is the wrong architecture

[CarlAllenn]

Defect

Every org repo consuming wasm-pack through aqua resolves macos-arm64 to the x86_64 tarball although the pinned version ships a native arm64 asset. Identical in edtf's and release-lab's locks (asset id 420850460):

[tools."aqua:rustwasm/wasm-pack"."platforms.macos-arm64"]
url = ".../v0.15.0/wasm-pack-v0.15.0-x86_64-apple-darwin.tar.gz"

Cause, re-verified 2026-08-24 against aqua-registry HEAD (pkgs/wasm-bindgen/wasm-pack/registry.yaml): the current-version entry carries rosetta2: true and a single goos: linux override mapping arm64: aarch64; there is no darwin case, so on darwin/arm64 rosetta2 selects the amd64 asset. The version boundary is exact and re-measured today against the release assets: aarch64-apple-darwin first appears in v0.14.0 (absent in v0.13.1), so rosetta2 is correct through 0.13.1 and wrong from 0.14.0 on. No existing upstream issue or PR covers this (searched aquaproj/aqua-registry for wasm-pack, 2026-08-24: only version-bump and transfer PRs).

Two consequences; the second is the org's: arm64 macOS developers run wasm-pack under emulation, and the checksum + provenance pinned for the platform called macos-arm64 are those of an x86_64 binary — a pinned attestation that does not describe the declared platform is a weaker claim than it looks.

Decided build

Decided 2026-08-24, both halves:

Upstream (authorized by Carl 2026-08-24, conditions binding): file one issue on aquaproj/aqua-registry, using their template (.github/ISSUE_TEMPLATE/05-bug-report.yml is the fit), only after re-checking at filing time that (a) HEAD still lacks the darwin override and (b) no issue/PR has appeared since this search — if either changed, record that here instead of filing. Content: the fix is a version_overrides entry constrained semver(">= 0.14.0") adding a goos: darwin override arm64: aarch64 and dropping rosetta2 for those versions; include the measured asset boundary. One issue, no PR unless upstream asks — a PR is a second decision, escalate if invited.

Local, until upstream lands: the belt carries the correction so macos-arm64 resolves the aarch64 asset — delivered, never copied per repo. The mechanism is measured, not assumed: mise/aqua support local registry overrides in more than one shape (a repo-level [tools] URL/backend override, an aqua local registry entry); the build measures which shape (1) survives --locked with a real per-platform checksum entry, (2) is deliverable through the belt's existing [env]/config channel, and (3) disappears cleanly when the upstream fix arrives (pin bump makes it dead code that a comment dates). If no shape measurably expresses it, the fallback is a dated, loud exception: a comment at the pin recording that macos-arm64 runs x86_64-under-Rosetta and why, plus a belt check that reds the day the lock's macos-arm64 URL and the release's aarch64 asset can finally agree — silence is the one forbidden outcome.

The sweep: this was found by eye. Script the same check across every aqua-backed tool in the belt: for each tool with per-platform lock entries, compare each platform key's resolved asset name against the architecture the key declares; report mismatches. Run it once, record results here; if it finds a second mismatch, that is a new issue per tool, filed with the measurement. Decide at build time whether the script graduates into audit:* (network-bound: it reads release asset lists) — default yes, as audit:lock-arch, since a one-shot check is a claim that decays.

Rejected, recorded: accepting emulation silently (the attestation mismatch is the harm); per-repo overrides (the belt delivers, #445); filing upstream without the freshness re-check (Carl's condition: real, unfiled, single, templated).

Canon consequence

Whatever shape lands is belt-delivered and reaches edtf and release-lab (today's wasm consumers) at their pin bump. When upstream merges and the aqua-registry pin advances past it, the local correction is deleted in the same PR that bumps.

Done when

• the upstream issue exists (linked here) or the freshness re-check found it fixed/filed and says so here
• mise install --locked on an arm64 mac resolves wasm-pack to …aarch64-apple-darwin.tar.gz with a matching checksum — measured, lock diff quoted — OR the dated loud exception plus its watchdog check exist
• the sweep has run across all aqua-backed belt tools with results recorded here; any second mismatch is its own filed issue
• edtf and release-lab locks show the corrected platform entry at their next regeneration

Sequencing

Independent of the release path; no lab run. Not blocked (upstream filing is authorized with conditions). Shares mise/config.toml/mise.lock with other belt lanes — own PR. Refs #810, #445.

[CarlAllenn]

Build record: mechanism measured, delivery matrix, sweep results

All of the below is mise lock / mise install run on mise 2026.8.3,
macos-arm64, 2026-08-24. The belt was removed from each probe with
MISE_CONFIG_DIR=$(mktemp -d); nothing here is read from documentation.

The mechanism

mise setting aqua.registries — "Aqua registry sources to load before
the baked-in registry". Supplying a corrected wasm-pack registry document
that way makes mise lock write:

[tools."aqua:rustwasm/wasm-pack"."platforms.macos-arm64"]
-checksum = "sha256:d3f1a4a33e95f8f0d7801b024e08624c479999ac96aa150908b2394015cd0363"
-url = ".../v0.15.0/wasm-pack-v0.15.0-x86_64-apple-darwin.tar.gz"
-url_api = ".../releases/assets/420850460"
+checksum = "sha256:0abff4a03d670b6c00ea31d0e1608a72407e355f3d3765e9c30eb45cd5b7e318"
+url = ".../v0.15.0/wasm-pack-v0.15.0-aarch64-apple-darwin.tar.gz"
+url_api = ".../releases/assets/420850469"

distinct from macos-x64 for the first time. mise install under
MISE_LOCKED=1 MISE_LOCKED_VERIFY_PROVENANCE=1 then downloads it, passes
the checksum, and produces Mach-O 64-bit executable arm64. Done-when
item 2 is satisfiable.

Fall-through is safe — measured, because it is the property that could
have broken every other tool: with a registry source containing only
wasm-pack, aqua:rhysd/actionlint still resolved from the baked registry
(actionlint_1.7.12_darwin_arm64.tar.gz) in the same run. Packages absent
from the source fall through; only the named package is overridden.

The death condition is not what the issue assumed. mise reads a
registry baked into its own binary (aqua.baked_registry, default
true), pinned at aqua-registry commit 6291c29d… — which I fetched and
diffed: byte-identical to HEAD for this package. So the defect is live
in the exact bytes mise reads, and an upstream merge will not reach us
when it lands. The correction dies on a mise snapshot bump, not on the
upstream fix. That is written at the setting line so the remover reads it
there.

Delivery matrix — why the shape is what it is

#	route	result
A	absolute file:// literal in [settings] of the global belt config	works (aarch64)
B	relative "aqua-registry.yaml" beside the belt config	silently 0 entries
B'	"./aqua-registry.yaml", "file://./…", "file://aqua-registry.yaml"	silently 0 entries
C	tera template "file://{{ env.ORG_BELT_DIR }}/…" in [settings]	not rendered, 0 entries
D	MISE_AQUA_REGISTRIES set from the belt's [env]	too late — resolves via the baked registry and writes the x86_64 entry
E	MISE_AQUA_REGISTRIES in the process env	works (aarch64)
F	https:// registry URL	transport works

Two of these deserve to be read twice. D is wrong-but-green: the env
var arrives after registry resolution, so the lock is written with one
entry, no warning, and the wrong architecture — the exact failure class
this issue exists to remove, reachable by trying to fix it. B/B' fail
with no diagnostic at all, and they contradict mise's own documentation,
which states relative entries resolve against the config file's directory.
On the pinned version they do not.

Because C and D are out, the belt cannot compute the path, and a shared
belt file cannot carry a machine-specific absolute one. Hence the built
shape: mise/aqua-registry.yaml in the canon, selected by a
SHA-pinned https:// URL in mise/config.toml. One literal, identical
on every machine and in CI, content-pinned by the commit SHA exactly like
every uses: pin, covering both carriers (local conf.d symlink and CI
MISE_GLOBAL_CONFIG_FILE) at once. Route E was considered and rejected as
insufficient: it is 48 sites across 17 workflow files and covers CI only,
leaving local arm64 developers — half the stated harm — emulated.

Sequencing amended: a commit cannot contain its own SHA (#227), so
this is an N-1 self-pin and ships as a two-PR sequence, not the single
"own PR" the Sequencing section names — PR 1 adds the registry document,
PR 2 adds the setting line naming PR 1's merged SHA.

Watch item, not filed

The B/B' relative-path behaviour is a mise defect, not an
aqua-registry one, and the authorisation on this issue covers exactly one
aqua-registry filing. It is recorded here and deliberately not filed;
any filing is a future decision. Its practical bite is that the documented
form of this setting is the one that silently does nothing.

The sweep

Script compares every lock platform key's declared architecture against
the architecture named by the asset it resolved. Run across 9 live repo
locks — 614 platform entries, 48 distinct tools. Five entries name no
architecture and were not judged (shellcheck-v0.11.0.zip ×4, which is
shellcheck's arch-agnostic Windows zip, and ruby-4.0.6.macos.tar.gz,
where jdx/ruby publishes exactly one macOS asset and there is no
alternative to pick). Everything else was judged.

Three mismatches, all one family:

• edtf and release-lab: aqua:rustwasm/wasm-pack macos-arm64 — this
  issue.
• org-github (the belt's own lock): committed macos-arm64 →
  committed-v1.1.11-x86_64-apple-darwin.tar.gz, byte-identical to
  macos-x64 (same checksum, same asset id 361544941). Same cause —
  rosetta2: true and no darwin arm64 case — and correctable:
  aarch64-apple-darwin first appears in v1.1.6 and the belt pins
  1.1.11. Filed as aqua resolves committed macos-arm64 to the x86_64 asset — a belt tool, so every arm64 machine in the org #854, not fixed here, per this issue's instruction
  that a second mismatch is its own issue per tool. It is materially worse
  than this one: committed is a belt tool on the commit-msg / pre-push
  / CI hot path, so it reaches every repo and every arm64 machine in the
  org, and its supported_envs also drops linux-arm64 from the lock
  entirely — mise.lock records whatever was resolved, not every platform the release targets #810's shape from the same registry defect.

The sweep found nothing outside this family.

[CarlAllenn]

Upstream filed: aquaproj/aqua-registry#59338

Carl's three conditions, satisfied in order and re-checked at filing time, not carried over from the earlier search:

1. Real and still live. Re-fetched pkgs/wasm-bindgen/wasm-pack/registry.yaml from HEAD immediately before filing: rosetta2: true still present in the current-version entry, goos: darwin override still absent (grep count 0). The only commit to touch that file since is the March 2026 repository transfer — no fix.
2. Unfiled. Re-searched at filing time: issues and PRs matching wasm-pack returned only the Renovate Dependency Dashboard and one closed unrelated issue; rosetta2 returned no open issues; no open PR has wasm-pack in its title.
3. Exactly one issue, on their template. Filed against 05-bug-report.yml, section for section, with their bug label.

The report is a real reproduction, not the registry analysis restated. Their template requires aqua info output, so rather than write something that looked like it, I installed aqua itself (2.62.3, via mise's github backend with artifact attestations verified) and ran it against the standard registry at v4.554.0:

$ aqua i        # darwin/arm64, aqua.yaml pinning wasm-bindgen/wasm-pack@v0.15.0
AQUA_ROOT_DIR/pkgs/…/v0.15.0/wasm-pack-v0.15.0-x86_64-apple-darwin.tar.gz/…/wasm-pack
wasm-pack: Mach-O 64-bit executable x86_64

while the release publishes wasm-pack-v0.15.0-aarch64-apple-darwin.tar.gz alongside it. So the defect is now demonstrated end to end in aqua proper, independently of mise — which also rules out the reading that this was only ever mise's aqua backend misbehaving. The filing includes the measured version boundary and the suggested semver(">= 0.14.0") override, and notes why the arm64: aarch64 replacement belongs under goos: darwin rather than in the shared map (windows/arm64 has no aarch64-pc-windows-msvc asset and still needs windows_arm_emulation).

No PR was offered or written, per the standing condition. If upstream invites one, that is the pre-flagged escalation and comes back here rather than being acted on.

[CarlAllenn]

Both PRs up; the shipped channel is proven, not inferred

#870 merged (c9a1c6c) — the correction, audit:lock-arch + 15 unit tests, and the scheduling legs. #882 open — the single aqua.registries line that selects it, pinned to c9a1c6c.

The earlier measurements in this thread were made through a file:// probe, which is what chose the shape. Before opening #882 I re-measured through the actual URL the belt now carries, because those are not the same claim:

mise parsing aqua registry from https://raw.githubusercontent.com/monumental-archive/.github/c9a1c6cc…/mise/aqua-registry.yaml
wasm-pack   macos-arm64  wasm-pack-v0.15.0-aarch64-apple-darwin.tar.gz  sha256:0abff4a0…
actionlint  macos-arm64  actionlint_1.7.12_darwin_arm64.tar.gz          (baked, untouched)
committed   macos-arm64  committed-v1.1.11-x86_64-apple-darwin.tar.gz   (#854, unchanged)

The wasm-pack checksum is distinct from macos-x64 for the first time; actionlint proves fall-through still works with the source in place; committed proves the correction is scoped to what it names. The pin itself was derived rather than transcribed — git log origin/main -1 -- mise/aqua-registry.yaml, confirmed equal to the squash commit — and the URL was checked live (200, bytes identical to git show <sha>:mise/aqua-registry.yaml) before a line was written pointing at it.

Done when — status

• the upstream issue exists — wasm-bindgen/wasm-pack: darwin/arm64 resolves the x86_64 asset although aarch64-apple-darwin exists since v0.14.0 aquaproj/aqua-registry#59338, all three conditions re-checked at filing time
• mise install --locked on an arm64 mac resolves the aarch64 asset with a matching checksum — lock diff quoted above and earlier; the install yields Mach-O 64-bit executable arm64. No dated exception was needed, so that branch of the Decided build is unused.
• the sweep has run across all aqua-backed belt tools, results recorded — 9 locks, 614 platform entries, 48 tools; the one second mismatch is aqua resolves committed macos-arm64 to the x86_64 asset — a belt tool, so every arm64 machine in the org #854
• edtf and release-lab locks show the corrected entry at their next regeneration — the only item left, and it is downstream of their pin bumps rather than of this lane

One thing this issue got wrong, worth keeping

The Decided build assumed the local correction would die when upstream merged. It will not. mise reads a registry compiled into its own binary, and the snapshot it carries was measured byte-identical to aqua-registry HEAD — so the retirement trigger is a mise version bump, and an upstream merge alone changes nothing here. That is now written at the setting line with a mechanical removal test, because the wrong belief was the one that would have left dead configuration in the belt for months while everyone waited for the wrong signal.

[CarlAllenn]

Known cost of the URL shape, recorded so it is not rediscovered: the pin names one commit's version of mise/aqua-registry.yaml, so every future edit to that file is an N-1 two-PR sequence — the edit lands, then a following commit bumps the pin to it. First recurrence is #854, whose "same PR" condition had to be amended because of exactly this.