Linux FFmpeg is downloaded, extracted and executed with no checksum verification #518

download_linux_ffmpeg fetches a binary from a rolling URL on a single host, extracts it, marks it executable and runs it -- with no integrity check of any kind. The Windows and macOS paths both verify.

The defect

desktop/src-tauri/src/main.rs:3723-3745 (verified):

let archive = downloads.join("ffmpeg-linux.tar.xz");
download_file(&url, &archive, Duration::from_secs(30 * 60), "FFmpeg")?;
// Extract with the system tar ...
let status = Command::new("tar").args(["-xJf", ...])

No SHA256 constant exists for this path, and nothing verifies the archive between download and extraction. The URL is:

https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz

A rolling artifact -- its contents change over time -- served from a single non-CDN host.

Inconsistent with both other platforms

• Windows verifies against BtbN's published checksums.sha256 (main.rs:4038-4051).
• macOS verifies against four pinned hashes (main.rs:3862-3893).
• Linux verifies nothing.

verify_ffmpeg only proves the binary runs and has the required encoders. It proves nothing about authenticity.

Compounding: an unverified .tar.xz is unpacked by the system tar, whose traversal and symlink behaviour is not the crate-level protection used for the runtime pack. So a hostile archive gets both code execution via the binary and a less-guarded extraction.

Fix

Upstream publishes a .md5 companion alongside the release. The Windows path already implements exactly this shape -- fetch the companion, verify before extracting. Either adopt that, or pin a specific version plus its SHA256 the way macOS does.

If neither is acceptable because the artifact is genuinely rolling, then at minimum extract via the tar crate rather than the system binary, so traversal protection is not left to whichever tar the host ships.