FFmpeg to Google: Fund us or stop sending bugs

Original Article ↗ Hacker News Discussion ↗

Responsible disclosure & OSS constraints

  • Core tension: 90‑day disclosure norms (Project Zero’s policy) were built for large vendors; many argue they don’t fit small, volunteer FOSS projects that can’t reliably turn fixes around on that timeline.
  • One side: once a vulnerability is known, keeping it private indefinitely is irresponsible; users deserve to know and decide their own mitigations.
  • Other side: for niche or low‑risk issues, early public disclosure just hands exploit ideas to attackers while maintainers lack capacity to fix them, turning “courtesy notice” into de facto pressure.

How serious is this FFmpeg bug?

  • Bug is a use‑after‑free in the LucasArts SANM/Smush codec (Rebel Assault 2 era).
  • Critics: this is an obscure 1990s “hobby codec”; calling it “medium impact” CVE slop wastes scarce maintainer time.
  • Counterpoint: the codec is compiled in and autodetected in default builds on major distros; any crafted file can trigger it. UAFs are often RCE‑relevant, so treating it as minor is misleading.

Google’s role: contribution vs extraction

  • Many comments argue: if Google can pay people and AI to find FFmpeg bugs, it should also pay to fix them or fund maintainers directly, rather than “outsourcing” remediation to unpaid volunteers under a countdown.
  • Others point out: Google already contributes codecs and patches, fuzzing infrastructure, and hires FFmpeg devs as consultants; a high‑quality bug report is itself a significant contribution.
  • Disagreement whether public criticism will push corporations to fund more, or instead to disengage entirely from upstream.

AI, fuzzing, and “CVE slop”

  • Maintainers report rising volume of automated, often marginal vulnerabilities and low‑context CVEs, which are costly to triage.
  • Some see this as “AI slop” and a major burnout driver; others note the showcased report was human‑written, detailed, and clearly not slop.

Security vs obscurity and user risk

  • Strong split between “better buggy‑and‑documented than buggy‑and‑unknown” and “publishing hard‑to‑exploit issues just arms attackers.”
  • Many emphasize downstreams can act (sandbox FFmpeg, disable codecs, patch forks) only if vulnerabilities are public.

What should FFmpeg and similar projects do?

  • Suggested responses:
    • Mark such issues low‑priority and fix when possible.
    • Disable obscure codecs by default or move them behind build flags.
    • Clarify security posture (“best effort” vs “high priority”).
    • Pursue funding/consulting/dual‑licensing models or foundations.
  • Underlying fear: if expectations and workload stay mismatched, key maintainers will simply quit, leaving widely‑used infrastructure effectively unmaintained.