Repository navigation
macOS FFmpeg download runs without checksum verification #172
Description
The macOS setup path downloads FFmpeg and ffprobe from evermeet.cx, extracts the binaries, marks them executable, and then verifies them by running ffmpeg -version.
I didn’t see a checksum verification step before execution.
The Windows path looks safer here. It downloads the default gyan.dev .sha256 companion file and compares the archive hash before extracting/running it. The runtime pack also has SHA256 verification.
So prob more of a macOS-only thing.
Risk is that a bad FFmpeg/ffprobe download could end up getting executed as the user during setup.
Not sure if evermeet has a stable checksum source that fits the current flow. If not, maybe the safer path is pinning known hashes in a manifest, using GitHub release-hosted assets, or requiring an explicit hash for override URLs.
Activity
thcp commentedon Jun 2, 2026
Hi @omglazrgunpewpew , thanks for the report, this will be addressed on the next release
fix: verify macOS FFmpeg download with a pinned SHA256 (#172) (#192)
thcp commentedon Jun 5, 2026
Hi @omglazrgunpewpew, finally fixed on
main(#192).The macOS path now verifies a SHA256 checksum before the FFmpeg/ffprobe binaries are extracted or executed. On a mismatch it deletes the download and aborts setup with a clear error, so a corrupt or tampered binary is never run.
As you noted, evermeet publishes no
.sha256companion (only a GPG signature and a size), so the runtime fetch-and-compare approach used for gyan.dev on Windows does not apply. We went with your first suggestion: pin a specific evermeet versioned build (ffmpeg/ffprobe8.1.1) and its known SHA256, captured at build time, and verify against that. The rollinggetrelease/latestURLs were swapped for the pinned versioned zips so the pinned hash stays valid. Custom override URLs (STEMDECK_FFMPEG_URL) can supply their own hash viaSTEMDECK_FFMPEG_SHA256/STEMDECK_FFPROBE_SHA256, otherwise verification is skipped, matching the existing Windows override behaviour.Trade-off: the pinned version and hashes get bumped together when we update FFmpeg, and evermeet eventually removes old versioned builds. Re-hosting the binaries as our own GitHub release assets (your third suggestion) is a sensible next step for retention, and we may move to that later.
This will ship in the next release. If you would like to keep up with updates, feel free to follow @stemdeckapp on Twitter.
And again, thanks again for the report.
Ship YouTube's challenge solver without costing anyone a reinstall (#446