Most active commenters

    ←back to thread

    FFmpeg to Google: Fund us or stop sending bugs

    (thenewstack.io)
    1125 points CrankyBear | 15 comments | 11 Nov 25 18:32 UTC | HN request time: 0.001s | source | bottom
    Show context
    woodruffw ◴[11 Nov 25 19:16 UTC] No.45891521[source]▶
    I’m an open source maintainer, so I empathize with the sentiment that large companies appear to produce labor for unpaid maintainers by disclosing security issues. But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it, or would otherwise need to accept the reputational hit that comes with not triaging security reports. That’s sometimes perfectly fine (it’s okay for projects to decide that security isn’t a priority!), but you can’t have it both ways.
    replies(13): >>45891613 #>>45891749 #>>45891930 #>>45892032 #>>45892263 #>>45892941 #>>45892989 #>>45894805 #>>45896179 #>>45897077 #>>45897316 #>>45898926 #>>45900786 #
    Msurrow ◴[11 Nov 25 19:22 UTC] No.45891613[source]▶
    My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it.

    To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works

    replies(5): >>45891699 #>>45891755 #>>45891844 #>>45893088 #>>45898343 #
    vadansky ◴[11 Nov 25 19:28 UTC] No.45891699[source]▶
    On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? I mean someone could already be using the vulnerability regardless of what Google does.
    replies(9): >>45891756 #>>45891762 #>>45891975 #>>45892022 #>>45892359 #>>45892632 #>>45893251 #>>45895054 #>>45900572 #
    1. cogman10 ◴[11 Nov 25 19:35 UTC] No.45891762[source]▶
    Sure but how.

    Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what?

    We are talking about software commonly for end users deployed to encode their own media. Something that rarely comes in untrusted forms. For an exploit to happen, you need to have a situation where an attacker gets out a exploited media file which people commonly transcode via FFMPEG. Not an easy task.

    This sure does matter to the likes of google assuming they are using ffmpeg for their backend processing. It doesn't matter at all for just about anyone else.

    You might as well tell me that `tar` has a CVE. That's great, but I don't generally go around tarring or untarring files I don't trust.

    replies(4): >>45891799 #>>45891846 #>>45891931 #>>45892019 #
    2. omnicognate ◴[11 Nov 25 19:38 UTC] No.45891799[source]▶
    AIUI, (lib)ffmpeg is used by practically everything that does anything with video, including such definitely-security-sensitive things as Chrome, which people use to play untrusted content all the time.
    replies(2): >>45891853 #>>45892520 #
    3. manquer ◴[11 Nov 25 19:42 UTC] No.45891846[source]▶
    Ffmpeg is a versatile toolkit used in lot of different places.

    I would be shocked if any company working with user generated video from the likes of zoom or TikTok or YouTube to small apps all over which do not have it in their pipeline somewhere.

    replies(1): >>45894700 #
    4. cogman10 ◴[11 Nov 25 19:43 UTC] No.45891853[source]▶
    hmm, didn't realize chrome was using ffmpeg in the background. That definitely makes it more dangerous than I supposed.

    Looks like firefox does the same.

    replies(2): >>45891970 #>>45902532 #
    5. adastra22 ◴[11 Nov 25 19:50 UTC] No.45891931[source]▶
    Upload a video to YouTube or Vimeo. They almost certainly run it through ffmpeg.
    6. conradev ◴[11 Nov 25 19:53 UTC] No.45891970{3}[source]▶
    Firefox has moved some parsers to Rust: https://github.com/mozilla/mp4parse-rust
    replies(1): >>45892360 #
    7. conradev ◴[11 Nov 25 19:57 UTC] No.45892019[source]▶
    ffmpeg is also megabytes of parsing code, whereas tar is barely a parser.

    It would be surprising to find memory corruption in tar in 2025, but not in ffmpeg.

    8. rebelwebmaster ◴[11 Nov 25 20:25 UTC] No.45892360{4}[source]▶
    Firefox also does a lot of media decoding in a separate process.
    9. godshatter ◴[11 Nov 25 20:39 UTC] No.45892520[source]▶
    Then maybe the Google chrome devs should submit a PR to ffmpeg.
    replies(2): >>45892770 #>>45898129 #
    10. omnicognate ◴[11 Nov 25 21:00 UTC] No.45892770{3}[source]▶
    Sure. And fund them.
    11. deaddodo ◴[12 Nov 25 00:12 UTC] No.45894700[source]▶
    There are alternatives such as gstreamer and proprietary options. I can’t give names, but can confirm at least two moderately sized startups that use gstreamer in their media pipeline instead of ffmpeg (and no, they don’t use gst-libav).

    One because they are a rust shop and gstreamer is slightly better supported in that realm (due to an official binding), the other because they do complex transformations with the source streams at a basal level vs high-level batch transformations/transcoding.

    replies(1): >>45895861 #
    12. manquer ◴[12 Nov 25 02:46 UTC] No.45895861{3}[source]▶
    There are certainly features and use cases where gstreamer is better fit than ffmpeg.

    My point was it would be hard to imagine eschewing ffmpeg completely, not that there is no value for other tools and ffmpeg is better at everything. It is so versatile and ubiquitous it is hard to not use it somewhere.

    In my experience there usually is always some scenarios in the stack where throwing in ffmpeg for a step is simpler and easier even if there no proper language binding etc, for some non-core step or other.

    From a security context that wouldn't matter, As long it touches data, security vulnerabilities would be a concern.

    It would be surprising, not that it would impossible to forgo ffmpeg completely. It would be just like this site is written Lisp, not something you would typically expect not impossible.

    replies(1): >>45896569 #
    13. deaddodo ◴[12 Nov 25 05:08 UTC] No.45896569{4}[source]▶
    I wasn’t countering your point, I just wanted to add that there are alternatives (well, an alternative in the OSS sphere) that are viable and well used outside of ffmpeg despite its ubiquity.
    14. walletdrainer ◴[12 Nov 25 09:29 UTC] No.45898129{3}[source]▶
    Chrome devs frequently do just that, Chrome just doesn’t enable this codec.
    15. xxs ◴[12 Nov 25 16:57 UTC] No.45902532{3}[source]▶
    Pretty much anything that has any video uses the library (incl. youtube)