Split out of #637, which fixes the symptoms. This is the source gap underneath it.
StemDeck downloads macOS FFmpeg from two places. The primary, shaka-project's static builds, publishes one binary per architecture and is selected by std::env::consts::ARCH, with four pinned hashes. The fallback, evermeet.cx, is a single URL and a single hash used on both architectures, and it publishes Intel builds.
So on an Apple Silicon Mac, any time the primary is unreachable, the fallback hands over a binary the machine cannot execute. GitHub Releases being blocked or slow is enough to trigger it, which is what happened to the reporter in #637.
Rosetta 2 hides this when it is installed, which is why it does not affect everyone. It does not install itself here: a bare exec() never triggers the install-on-demand prompt that GUI apps get, so a Mac without Rosetta simply fails.
After #637 the failure is caught at setup, explains itself, and recovers on retry, and the user is pointed at softwareupdate --install-rosetta or STEMDECK_FFMPEG_URL. Both work. Neither is the app doing its job on its own.
What is actually needed is a second source that publishes an arm64 macOS build, pinned the way the existing four hashes are: downloaded, checksummed, and cross-checked against whatever the publisher states, before anything is committed. That verification is the work here, not the code change, which is small.
Worth deciding at the same time whether an Intel-only fallback should be used on Apple Silicon at all when Rosetta is absent, or whether it is better to fail immediately with the Rosetta instruction rather than download 80MB that cannot run.
Split out of #637, which fixes the symptoms. This is the source gap underneath it.
StemDeck downloads macOS FFmpeg from two places. The primary, shaka-project's static builds, publishes one binary per architecture and is selected by
std::env::consts::ARCH, with four pinned hashes. The fallback, evermeet.cx, is a single URL and a single hash used on both architectures, and it publishes Intel builds.So on an Apple Silicon Mac, any time the primary is unreachable, the fallback hands over a binary the machine cannot execute. GitHub Releases being blocked or slow is enough to trigger it, which is what happened to the reporter in #637.
Rosetta 2 hides this when it is installed, which is why it does not affect everyone. It does not install itself here: a bare
exec()never triggers the install-on-demand prompt that GUI apps get, so a Mac without Rosetta simply fails.After #637 the failure is caught at setup, explains itself, and recovers on retry, and the user is pointed at
softwareupdate --install-rosettaorSTEMDECK_FFMPEG_URL. Both work. Neither is the app doing its job on its own.What is actually needed is a second source that publishes an arm64 macOS build, pinned the way the existing four hashes are: downloaded, checksummed, and cross-checked against whatever the publisher states, before anything is committed. That verification is the work here, not the code change, which is small.
Worth deciding at the same time whether an Intel-only fallback should be used on Apple Silicon at all when Rosetta is absent, or whether it is better to fail immediately with the Rosetta instruction rather than download 80MB that cannot run.