harden(rsky-video): bound transcode CPU, memory, disk and runtime

[afbase]

Summary

Targets main, and carries #210's commit as a dependency. The hardening builds directly on the MOV
remux path introduced in #210, so this branch contains both commits: b17b22e (the fix) and 9ce330b
(this hardening). To review the hardening alone, read 9ce330b on its own. If #210 merges first, this
diff reduces to that commit automatically; if this one merges first, #210 becomes redundant and can be
closed.

Transcoding is the one place this service hands an attacker-supplied file to a CPU- and memory-hungry subprocess, and until now that subprocess ran with no ceiling of any kind: no deadline, no output cap, no thread cap, and no limit on how many could run at once. A single crafted upload could pin the box, and N concurrent uploads meant N concurrent ffmpeg processes competing for CPU, RAM and temp disk.

Ceilings

Every conversion now runs under transcode::Limits, all env-overridable:

Knob	Default	Bounds
TRANSCODE_TIMEOUT_SECS	120	Wall-clock per conversion. Overrunning ffmpeg is SIGKILLed and reaped.
TRANSCODE_MAX_CONCURRENT	half the cores, min 1	Total transcode CPU, memory and temp disk.
TRANSCODE_QUEUE_TIMEOUT_SECS	30	How long an upload waits for a slot before 429 — so waiters can't pile up unbounded.
TRANSCODE_MAX_OUTPUT_BYTES	2× MAX_VIDEO_SIZE	Expansion bombs: a small input that decodes into an enormous output.
TRANSCODE_THREADS	2	Per-process, so one conversion can't saturate every core.

Why not ffmpeg's -fs?

Because it does not work. -fs is silently ignored both for stream-copy remuxes and for re-encodes — verified against ffmpeg 8.1.2:

-fs 50000  -c copy       -> 158022 bytes written   (cap ignored)
-fs 20000  -c:v libx264  ->  68755 bytes written   (cap ignored)

Shipping -fs would have been a cap that does nothing. The ceiling is instead enforced by watching the output file and killing the process, which doesn't depend on ffmpeg honoring anything.

Other subprocess hardening

• kill_on_drop(true) — tokio does not kill a child when its future is dropped. Before this, a client that disconnected mid-upload left ffmpeg running to completion; repeated connect/disconnect was unbounded free CPU with no request left to attribute it to.
• Pinned demuxer + protocol whitelist — -f <format> pins ffmpeg to the format the magic bytes already implied, and -protocol_whitelist file keeps a crafted input from steering ffmpeg into a playlist-style demuxer that opens other local paths or URLs.
• Bounded stderr — -loglevel error -nostats keeps stderr small enough that ffmpeg can never block writing to a full pipe while we supervise it, and the capture itself is capped at 64KB. (It also makes failure messages more useful: real error lines instead of progress spam.)

Two fixes outside transcode.rs

DefaultBodyLimit was 5GB. upload_video takes the body as Bytes, which axum buffers entirely in memory before the handler runs — so the handler's own MAX_VIDEO_SIZE check (100MB) happened after the allocation and did nothing to prevent it. One request could force a multi-GB allocation; a few concurrently would OOM the host. The layer now uses max_video_size, so oversized uploads are refused with 413 while streaming.

No graceful shutdown. axum::serve had none, so a redeploy's SIGTERM killed in-flight uploads after their job rows were created, leaving jobs stuck. It now drains on SIGTERM/SIGINT — relevant given a redeploy is imminent.

Verification

cargo test -p rsky-video: 11 passed. With -- --ignored: 4 passed. Clippy: no new warnings. cargo fmt: clean.

• saturated_queue_is_rejected_with_429 — turns uploads away instead of queueing forever, without spawning ffmpeg at all.
• deadline_kills_a_slow_transcode — deadline fires and the permit is released, so one slow upload can't wedge a slot permanently.
• output_ceiling_rejects_oversized_output — VideoTooLarge rather than an unbounded write.
• gif_converts_to_an_mp4 / mov_remux_yields_an_mp4_brand — both real paths still convert correctly with the pinned demuxer and whitelist in place.

The kill was also verified out of band, since a TTL that doesn't actually kill is worth nothing: a 720p encode interrupted at 1ms leaves no surviving ffmpeg process, checked while that same encode was independently measured at 1.72s real / 3.70s user of work — so an unkilled process would still have been plainly visible.

Note

max_video_duration (90s) is config'd but enforced nowhere in the codebase — it predates this PR. I left it alone deliberately: the natural fix is ffmpeg -t, but that would silently truncate a user's video rather than reject it, which is a product decision rather than a hardening one. Worth a follow-up.

Related Issues

Follow-up to #210, which introduced the MOV remux path and made ffmpeg load user-controlled.

Changes

• Other (please specify): resource-exhaustion and subprocess hardening

Checklist

• I have tested the changes (including writing unit tests).
• I confirm that my implementation aligns with the canonical Typescript implementation and/or atproto spec
• I have updated relevant documentation. (New env vars are documented as doc comments in config.rs, matching how the existing ones are — this crate has no README.)
• I have formatted my code correctly
• I have provided examples for how this code works or will be used

🤖 Generated with Claude Code