Repository navigation
fix: verify macOS FFmpeg download with a pinned SHA256 (#172) - #192
Merged
Merged
Conversation
The macOS setup downloaded ffmpeg and ffprobe from evermeet.cx's rolling getrelease/latest URLs, extracted them, marked them executable, and ran them - with no integrity check. The Windows path already verifies a SHA256 companion before extracting; macOS had no equivalent, so a corrupt or tampered download could be executed as the user during setup. evermeet publishes no .sha256 companion (only a GPG signature and a size), so the runtime fetch-and-compare trick used for gyan.dev on Windows does not apply. Instead, pin a specific evermeet versioned build (ffmpeg/ffprobe 8.1.1) and its SHA256, captured at build time, and verify the archive before it is extracted or chmod'd. The download sizes matched evermeet's signed release-info JSON when the hashes were captured. - Switch the macOS URLs from getrelease/latest to the pinned versioned zips so the pinned hash stays valid. - verify_pinned_sha256() rejects a mismatch and deletes the file so a bad binary is never run; expected_ffmpeg_sha256() enforces the pinned hash for the default URLs and honours an explicit STEMDECK_FFMPEG_SHA256 / STEMDECK_FFPROBE_SHA256 for custom override URLs (else skips, matching the Windows override behaviour). - Reuses the existing sha256_file() helper and sha2 crate. Adds 4 Rust unit tests (match accepted, mismatch removes the file, None skips, default-URL pins / unknown override skips). cargo test and cargo fmt pass; cargo check is clean. Bump the version and BOTH pinned hashes together when updating FFmpeg.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #172.
Problem
macOS setup downloaded
ffmpeg/ffprobefrom evermeet.cx's rollinggetrelease/latestURLs, extracted them, marked them executable, and ran them - with no integrity check. The Windows path already verifies a SHA256 companion before extracting, so a corrupt or tampered macOS download could be executed as the user during setup.Why not mirror the Windows trick
Windows fetches gyan.dev's
.sha256companion at runtime and compares. evermeet publishes no SHA companion - only a GPG signature and a size. So there is no same-flow hash to fetch.Approach (chosen: pin a known hash)
Pin a specific evermeet versioned build and its SHA256, captured at build time, and verify the archive before it is extracted or
chmod'd.getrelease/latestto the pinned versioned zips (ffmpeg-8.1.1.zip,ffprobe-8.1.1.zip) so the pinned hash stays valid.verify_pinned_sha256()rejects a mismatch and deletes the file so a bad binary is never run.expected_ffmpeg_sha256()enforces the pinned hash for the default URLs and honours an explicitSTEMDECK_FFMPEG_SHA256/STEMDECK_FFPROBE_SHA256for custom override URLs, otherwise skips - matching the Windows override behaviour.sha256_file()helper andsha2crate; no new dependencies.Trade-off: the version + both hashes must be bumped together when updating FFmpeg, and evermeet eventually removes old versioned builds (the existing
STEMDECK_FFMPEG_URLoverride remains an escape hatch). Re-hosting the binaries on our own GitHub releases for retention is a sensible future step.Verification
Noneskips; default URL pins / unknown override skips).cargo test: 9 passed.cargo fmt --checkandcargo checkclean.Note: CI does not run
cargo clippy; pre-existing clippy warnings in unrelated CUDA/torch code (surfaced only by newer local toolchains) are out of scope here.File:
desktop/src-tauri/src/main.rs.