Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

331–340 of 913 posts

Re: FFmpeg to Google: Fund us or stop sending bugs

#331

Post by nightshift1 »

lenerdenator wrote: post #284
ryandrake wrote: post #263

Earlier quoted context omitted.

Well, it's open source and built by volunteers, so nobody is obligated to fix it. If FFmpeg volunteers don't want to fix it or don't have the time/bandwidth to fix it, then they won't fix it. Like any other bug or CVE in any other open source project. The burden doesn't necessarily need to be on anyone.

They aren't obligated to fix CVEs until they're exploited, and then, suddenly, they very much were obligated to fix the CVEs, and their image as FLOSS maintainers and as a project are very much tarnished.

I don't think anyone can force them to fix cve. Software is provided as-is. Can't be more straightforward as that.

Re: FFmpeg to Google: Fund us or stop sending bugs

#332

Post by toast0 »

Astronaut3315 wrote: post #322
skhameneh wrote: post #264

Earlier quoted context omitted.

I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…

I upstreamed a 1-line fix, plus tests, at my previous company. I had to go through a multi-month process of red tape and legal reviews to make it happen. That was a discouraging experience to say the least.

My favorite is when while you were working through all that, the upstream decided they need a CLA. And then you have to go through another round of checking to see if your company thinks it's ok for you to agree to sign that for a 1 line change.

Certainly easier to give a good bug report and let upstream write the change, if they will.

Re: FFmpeg to Google: Fund us or stop sending bugs

#333

Post by jsnell »

astrange wrote: post #314
MyOutfitIsVague wrote: post #23

Earlier quoted context omitted.

When you already work 40+ hours a week and big companies suddenly start an AI snowblower that shoots a dozen extra hours of work every week at you without doing anything to balance that (like, for instance, also opening PRs with patches that fix the bugs), the relationship starts feeling like being an unpaid employee of their project. What's the point of just showering these things with bug reports when the same tool…

The problem with security reports in general is security people are rampant self-promoters. (Linus once called them something worse.) Imagine you're a humble volunteer OSS developer. If a security researcher finds a bug in your code they're going to make up a cute name for it, start a website with a logo, Google is going to give them a million dollar bounty, they're going to go to Defcon and get a prize and I assume…

Except that the only people publicizing this bug were the people running the ffmpeg Twitter account. Without them it would have been one of thousands of vulnerabilities reported with no fanfare, no logos, and no conference talks.

Doesn't really fit with your narrative of security researchers as shameless glory hounds, does it?

Re: FFmpeg to Google: Fund us or stop sending bugs

#334

Post by deaddodo »

manquer wrote: post #61
cogman10 wrote: post #44

Earlier quoted context omitted.

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 do…

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.

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.

Re: FFmpeg to Google: Fund us or stop sending bugs

#335

Post by colonwqbang »

astrange wrote: post #311
zxspectrum1982 wrote: post #77

Earlier quoted context omitted.

Easy: ffmpeg discontinues or relicenses some ffmpeg functionality that AWS depends on for those product alines and AWS is screwed. I've seen that happen in other open source projects.

ffmpeg cannot relicense anything because it doesn't own anything. The contributors own the license to their code.

Relicensing isn't necessary. If you violate the GPL with respect to a work you automatically lose your license to that work.

It's enough if one or two main contributors assert their copyrights. Their contributions are so tangled with everything else after years of development that it can't meaningfully be separated away.

Re: FFmpeg to Google: Fund us or stop sending bugs

#336

Post by dotancohen »

Wowfunhappy wrote: post #318
jsnell wrote: post #289

Earlier quoted context omitted.

It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as t…

Ffmpeg makes it trivial to enable and disable individual codecs at compile time. Perhaps it's the Linux distros that need to make a change here?

Every change breaks somebody's workflow.

Re: FFmpeg to Google: Fund us or stop sending bugs

#337

Post by foobarchu »

dtech wrote: post #105
zxspectrum1982 wrote: post #75

Earlier quoted context omitted.

Google is not paying anyone to find bugs. They are running AIs indiscriminately.

Someone is making the tools to find these bugs. It's not like they're telling ChatGPT "go find bugs lol"

And running those models on large codebases like these isnt anywhere close to free either.

Re: FFmpeg to Google: Fund us or stop sending bugs

#338

Post by dotancohen »

Brian_K_White wrote: post #310
rcxdude wrote: post #295

Earlier quoted context omitted.

If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.

More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place. Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have th…

The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.

Re: FFmpeg to Google: Fund us or stop sending bugs

#339

Post by ikiris »

HDThoreaun wrote: post #320
jsnell wrote: post #60

Earlier quoted context omitted.

> 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. That is not an accurate description? Project Zero was using a 90 day disclosure policy from the start, so for over a decade. What changed[0] in 2025 is that they disclose earlier than 90 days that there is an issue ,…

Publishing the vulnerability is a demand to fix it. It threatens to cause harm to the reputation of the maintainer if left unfixed.

No, publishing the vulnerability is the right thing to do for a secure world because anyone can find this stuff including nation states that weaponize it. This is a public service. Giving the dev a 90 day pre warn is a courtesy.

Expecting a reporter to fix your security vulnerabilities for you is entitlement.

If your reputation is harmed by your vulnerable software, then fix the bugs. They didn’t create the hazzard they discovered it. You created it, and acting like you’re entitled to the free labor of those that gave you the heads up is insane, and trying to extort them for their labor is even worse.

Re: FFmpeg to Google: Fund us or stop sending bugs

#340

Post by dotancohen »

inkysigma wrote: post #210
nemothekid wrote: post #149

Earlier quoted context omitted.

> 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? Yes? It's in the license > NO WARRANTY > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANT…

Not being told the existence of bugs is different from having a warranty on software. How would you submit a patch on a bug you were not aware of? Google should provide a fix but it's been standard to disclose a bug after a fixed time because the lack of disclosure doesn't remove the existence of the bug. This might have to be rethought in the context of OSS bugs but an MIT license shouldn't mean other people can't d…

Google publicly disclosing the bug doesn't only let affected users know. It also lets attackers know how they can exploit the software.

Holding public disclosure over the heads of maintainers if they don't act fast enough is damaging not only to the project, but to end users themselves also. There was no pressing need to publicly disclose this 25 year old bug.

Post reply on HN