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

881–890 of 913 posts

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

#881

Post by tpmoney »

Orygin wrote: post #877
tpmoney wrote: post #857

Earlier quoted context omitted.

A bug is a bug, regardless of the intent of the insertion. You have no idea if this bug was or wasn't intentionally inserted. It's of course very likely that it wasn't, but you don't and can't know that, especially given that malicious bug insertion is going to be designed to look innocent and have plausible deniability. Likewise, you don't know that the use of the XZ backdoor was imminent. For all you know the inten…

A 25 years old bug in software is not the same as a backdoor (not a bug, a full on backdoor..). The bug is so old if someone put it there intentionally, well congrats on the 25yo 0day. Meanwhile the XZ backdoor was 100% meant to be used. I didn't say when and that doesn't matter, there is a malicious actor with the knowledge to exploit it. We can't say the same regarding the bug in a 1998 codec that was found by exte…

> Absolutely, but should the patch be done asap at the cost of other maybe more important security patches? Maybe, maybe not. Not all bugs are security vulns, and not all security vulns are exploitable

I fully agree which is why I really don’t understand why everyone is all up in arms here. Google didn’t demand that this bug get fixed immediately. They didn’t demand that everything be dropped to fix a 25 year old bug. They filed a (very good and detailed) bug report to an open source product. They gave a private report out of courtesy and an acknowledgment of the tradeoffs inherent in public bug disclosure, but ultimately a bug is a bug, it’s already public because the source code is public. If the ffmpeg devs didn’t feel it was important to fix right away, nothing about filing a bug report, privately or publicly changes any of that.

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

#882

Post by tpmoney »

troupo wrote: post #878
tpmoney wrote: post #858

Earlier quoted context omitted.

According to the ffmpeg maintainer's own website (fflabs.eu) Google is spending plenty of dimes helping to fix issues in ffmpeg. Certainly they're spending enough dimes for the maintainers to proudly display Google's logo on their site as a customer of theirs.

Here's ffmpeg's site: https://www.ffmpeg.org I fail to see a single Google logo. I also didn't know that Google sonehow had a contract with ffmpeg to be their customer.

Yes and if you look on ffmpeg’s site you’ll find a link where they promote hiring their devs independently as consultants for ffmpeg work. Note the names of those maintainers. Now go to fflabs.eu, observe that they are an ffmpeg consulting firm, scroll down on the main page and observe the Google logo among their promoted list of customers. Now click on the “team” link and check out the names of the people that run fflabs. Notice that they are some of the very same people listed in the ffmpeg main site. Ergo Google pays ffmpeg developers to work on ffmpeg.

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

#883

Post by tpmoney »

Y-bar wrote: post #767
tpmoney wrote: post #761

Earlier quoted context omitted.

I mean if we’re going to do sloppy analogies, a bug report for open source software as widely used as ffmpeg is more like “I noticed the trees in the back corner of your free apple orchard are producing apples with trace amounts of heavy metals. I did some literal digging and sent some soil off to the labs and it looks like your back corner field may be contaminated. Here’s a heads up about that, and also just FYI in…

Yes, this is a good illustration why The Copenhagen Interpretation of Ethics makes sense when Ffmpeg is allowed to criticise the manner of actions of Google.

I think it’s a good example of why it makes no sense. People are saying they would rather a world where people unknowingly get heavy metal poisoning from apples at the free orchard rather than a world where people are informed that some of the apples in one part of the orchard may have heavy metals in it because the person letting people know about it didn’t also remediate the soil, even though they don’t own the orchard.

That is plainly ridiculous. An orchard without heavy metals is obviously an ideal world in this case, but a world where people are at least informed of the places where the heavy metals are is orders of magnitude better than one where they’re unknowing getting heavy metal poisoning.

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

#884

Post by esrauch »

kastagg wrote: post #810
esrauch wrote: post #147

Earlier quoted context omitted.

Is there really slop here though? It sounds like the specific case identified was a real use after free in an obscure file format but which is enabled by default. If it was slop they could complain that it was wasting their time on false or unimportant reports, instead they seem to be complaining that the program reported a legitimate security issue?

If a maintainer complains about slop bug reports, instead of assuming the worst of the maintainer, it'll often be more productive to put yourself in their shoes and consider the context. An individual case may simply be the nth case in a larger picture (say, the straw that broke the camel's back). Whenever this nth case is observed, if you only consider that single case, a response also informed by detailed personal…

I'm very sympathetic to the premise of slop bug reports being harmful. Somehow zero of this thread has info about the slop bug reports though, it's all focused on one specific seemingly completely legitimate CVE issue.

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

#885

Post by Espressosaurus »

iscoelho wrote: post #142

It’s a reproducible use-after-free in a codec that ships by default with most desktop and server distributions. The recent iOS zero-day (CVE-2025-43300) targeted the rarely used DNG image format. How long before this FFMPEG vulnerability is exploited to compromise legacy devices in the wild, I wonder? I’m not a fan of this grandstanding for arguably questionable funding. (I surely would not fund those who believe the…

DNG isn't exactly rarely used, it's Adobe's open raw format and lots of image processing programs read and write it.

It's not a codec made for one game back in 1994, it's still in very active use today if you're using such a rare and uncommon program as Photoshop.

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

#886

Post by GabrielTFS »

astrange wrote: post #351
jsnell wrote: post #333

Earlier quoted context omitted.

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?

How do they know that next week it's not going to be one of those 10 page Project Zero blog posts? (Which like all Google engineer blog posts, usually end up mostly being about how smart the person who wrote the blog post is.) Note FFmpeg and cURL have already had maintainers quit from burnout from too much attention from security researchers.

If Google wanted nothing more than to simply make blog posts, why wouldn't they just only report the big bugs that they can make blog posts out of (and avoid having to spend any resources on finding the rest) ?

I don't know if you'd be satisfied with that, but certainly this would allow them to easily make the blog posts you seem to be complaining about, all while making the load on maintainers rather minimal, at least insofar as blog posts appear to be quite infrequent compared to the total amount of vulnerabilities they report - around 20 vulnerability reports per year certainly seems like a manageable load for the entire FOSS community to bear, especially given almost none of these 20 yearly vulnerability reports would go to ffmpeg (if not literally none, given the Project Zero blog has 0 search results for "ffmpeg" or "libav"), and a significant portion of their blog posts aren't even about FOSS at all but instead about proprietary software like the operating systems Microsoft and Apple make.

I do think such a thing would be bad for everyone, though (including the ffmpeg developers themselves, to be honest) - Project Zero is good for everyone's security, in my opinion, and even if all FOSS developers were to universally decide to reject all Project Zero reports that don't come with a patch, and Google decided to still not make such patches, people being able to know that these vulnerabilities exist is still a good thing nonetheless - certainly much better than more vulnerabilities being left in for malicious actors to discover and use in zero-day attacks.

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

#887

Post by koolala »

testdelacc1 wrote: post #572
koolala wrote: post #537

Earlier quoted context omitted.

They totally broke CSGO Legacy's code to push its sequel CS2 and won't accept fixes for it because it's 'not being supported'.

To be clear, both of those are closed source, proprietary games owned by Valve. It makes sense for them to want to consolidate their player base in one game.

https://github.com/ValveSoftware/csgo-osx-linux/issues/4047

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

#888

Post by tombert »

izacus wrote: post #854
tombert wrote: post #802

Earlier quoted context omitted.

Maybe those people shouldn’t be doing free labor to give me free libraries either.

Maybe such sociopath ideas should be shunned in any healthy society.

I dispute heavily being called a “sociopath” because I feel people should be paid for their labor and that it shouldn’t be taken for granted.

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

#889

Post by Orygin »

tpmoney wrote: post #881
Orygin wrote: post #877

Earlier quoted context omitted.

A 25 years old bug in software is not the same as a backdoor (not a bug, a full on backdoor..). The bug is so old if someone put it there intentionally, well congrats on the 25yo 0day. Meanwhile the XZ backdoor was 100% meant to be used. I didn't say when and that doesn't matter, there is a malicious actor with the knowledge to exploit it. We can't say the same regarding the bug in a 1998 codec that was found by exte…

> Absolutely, but should the patch be done asap at the cost of other maybe more important security patches? Maybe, maybe not. Not all bugs are security vulns, and not all security vulns are exploitable I fully agree which is why I really don’t understand why everyone is all up in arms here. Google didn’t demand that this bug get fixed immediately. They didn’t demand that everything be dropped to fix a 25 year old bug…

In the end, a report saying "fix this within 90 days or this gets public" for small-ish bugs like this is a kind of demand. Do this or this gets out and you'll have to make an express release to fix it anyway.

I can understand that stance for serious bugs and security vulnerabilities. I can understand such delays for a company with a big market cap to put pressure on them. But these delays are exactly like a demand put on the company: fix it asap or it gets public. We wouldn't have to do this if companies in general didn't need to get publicly pressured into fixing their stuff. Making it public has two objectives: Warn users they may be at risk, and force the publisher to produce a fix asap or else risk a reputation hit.

> If the ffmpeg devs didn’t feel it was important to fix right away, nothing about filing a bug report, privately or publicly changes any of that.

It does change how they report. Had they given more time or staggered their reports over time, Ffmpeg wouldn't have felt pressure to publish fixes asap. Even if the devs can say they won't fix, any public project will want to keep a certain quality level and not let security vulnerabilities get public.

In the end, had these reports been made by random security researchers, no drama would have happened. But if I see Google digging up 25 years old bugs, is it that much to expect them to provide a patch with it?

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

#890

Post by Orygin »

walletdrainer wrote: post #693
Orygin wrote: post #682

Earlier quoted context omitted.

It doesn't if you report lots of "security" issues (like this 25 years old bug) and give too little time to fix them. Nobody is against Google reporting bugs, but they use automatic AI to spam them and then expect a prompt fix. If you can't expect the maintainers to fix the bug before disclosure, then it is a balancing act: Is the bug serious enough that users must be warned and avoid using the software? Will disclos…

The timeline here is pretty long, and Google will provide an extension if you ask. What do you believe would be an appropriate timeline? >especially if you consider other security notices that may have a bigger impact. This is a bug in the default config that is likely to result in RCE, it doesn’t get that much worse than this.

> This is a bug in the default config that is likely to result in RCE, it doesn’t get that much worse than this.

Likely to get RCE? No. Not every UAF results in a RCE. Also, someone would have to find this and it's clearly not something you can easily spot from the code. Google did extensive fuzzing to discover it. The trade off is that Ffmpeg had to divert resources to fix this, when the chance it would have been discovered independently is tiny, and exploited even tinier.

Post reply on HN