gh-release picks 32-bit ARM asset on aarch64 hosts when the 64-bit asset is named "aarch64" #19

On aarch64 hosts (Apple Silicon, Graviton), gh-release installs the 32-bit ARM asset instead of the 64-bit one for any project that names its 64-bit asset aarch64 rather than arm64, which covers most Rust projects and anything using the Rust target triples.

Example

ghcr.io/devcontainers-extra/features/starship:1 on an Apple Silicon Mac (Docker Desktop, linux/arm64 container):

$ uname -m
aarch64
$ file /usr/local/bin/starship
/usr/local/bin/starship: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped

Starship v1.27.0 publishes both starship-aarch64-unknown-linux-musl.tar.gz and starship-arm-unknown-linux-musleabihf.tar.gz, and the armv7 one is picked. Apple Silicon has no AArch32 support, so the binary runs under emulation: every prompt render took 340-450 ms, and its git_status module took 125 ms against 16 ms for a native git status in the same repo.

Cause

In asset_resolver.py:

1. The ARM64 pattern does not match aarch64 (L26):

   LinuxInformationDesk.Architecture.ARM64: r"([Aa]rm64|ARM64)",

   so the correct asset gets no positive architecture match.
2. On ARM64, plain -arm- names get a positive match (L289-L297):

   # if arm64 - accept also simple "arm/ARM" mentions
   if arch == LinuxInformationDesk.Architecture.ARM64:
       ... regex=r"\-ARM\-?|\-arm\-" ...

   which favours arm-unknown-linux-musleabihf. None of the 32-bit negative patterns (armv7, armhf, arm32) match arm-...-musleabihf, so it isn't filtered out either.

The same pattern gap means x86_64 hosts never filter out aarch64 assets as a wrong architecture.

Related

The same bug has been fixed one feature at a time in devcontainers-extra/features by bypassing nanolayer with uname -m:

• fix: UV feature instealls 32 bits arm binary in an aarch64 container features#150 (uv: 32-bit ARM binary in an aarch64 container, same diagnosis)
• [Bug]: heroku-cli broken on Apple Silicon host features#134 / Fix heroku-cli install script on ARM64 (aarch64) CPUs features#153 (heroku-cli: qemu-arm: Could not open '/lib/ld-linux-armhf.so.3')
• Fix release and arch selection for typst feature features#237 (typst: no aarch64 release selected on macOS hosts)
• [Bug]: Protocol buffer on arm64 - Exec format error features#83 (protoc on arm64: Exec format error, still open, likely the same cause)

Suggested fix

• Include aarch64 in the ARM64 pattern, e.g. r"([Aa]rm64|ARM64|[Aa]arch64|AARCH64)". That gives the right asset a positive match on arm64 hosts and filters it out on x86_64 hosts.
• Only apply the -arm- fallback when no arm64/aarch64 candidate is left, or treat eabi/eabihf names as 32-bit.