Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

441–450 of 913 posts

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

#441
post #42

Earlier quoted context omitted.

That is standard practice. It is considered irresponsible to not publicly disclose any vulnerability. The X days is a concession to the developers that the public disclosure will be delayed to give them an opportunity to address the issue.

Here's the question: Why is Google deliberately running an AI process to find these bugs if they're just going to dump them all on the FFmpeg team to fix? They have the option to pay someone to fix them. They also have the option to not spend resources finding the bugs in the first place. If they think these are so damn important to find that it's worth devoting those resources to, then they can damn well pay for fix…

> Why is Google deliberately running an AI process to find these bugs if they're just going to dump them all on the FFmpeg team to fix?

This is called fuzzing and it has been standard practice for over a decade. Nobody has had any problem with it until FFmpeg decided they didn’t like that AI filed a report against them and applied the (again, mostly standard at this point) disclosure deadline. FWIW, nobody would have likely cared except they went on their Twitter to complain, so now everyone has an opinion on it.

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

#442
post #61

Earlier quoted context omitted.

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

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.

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

#443
post #138

Earlier quoted context omitted.

I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.

Yeah it's more effort, but I'd argue that security through obscurity is a super naive approach. I'm not on Google's side here, but so much infrastructure is "secured" by gatekeeping knowledge.

Given that Google is both the company generating the bug reports and one of the companies using the buggy library, while most of the ffmpeg maintainers presumably aren't using their libraries to run companies with a $3.52 trillion dollar market cap, would you argue that going public with vulnerabilities that affect your own product before you've fixed them is also a naive approach?

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

#444
post #407

Earlier quoted context omitted.

They're actively making open source projects less secure by publishing bugs that the projects don't have the volunteers to fix I saw another poster say something about "buggy software". All software is buggy.

Publishing bugs that the project has so that they can be fixed is actively making the project more secure. How is someone going to do anything about it if Google didn’t do the research?

Did you see how the FFMPEG project patched a bug for a 1995 console? That's not a good use for the limited amount of volunteers on the project. It actively makes it less secure by taking away from more pertinent bugs.

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

#445

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.

If they are unable to fix CVEs in a timely manner, then it is very reasonable for people to judge them (accurately!) as being unable to fix CVEs in a timely manner. Maybe some people might even decide to use other projects or chip in to help out! However, it is dishonest to hide reports and pretend like bugs are being fixed on time when they are not.

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

#446

I would suggest that FFmpeg spin up a commercial arm that gets support contracts with Google, Amazon, etc, but with a tight leash so that it does not undermine the open source project. Would need clean guidance as to what the commercial arm does and does not. Probably could pull in millions per year.

According to https://xcancel.com/argvee/status/1986194861855478213#m, google is a customer of fflabs.eu (https://fflabs.eu) which is just such a "support contracts" arm. Certainly the fflabs.eu site claims at the bottom that Netflix, Google and Meta are all customers of theirs and the site also claims that their team is comprised of a number of ffmpeg contributors including the "lead maintainer" (https://fflabs.eu/about/).

Additionally, a search of the git commits shows a regular stream of commits from `google.com` addresses. So as near as I can tell, Google does regularly contribute code to the project, they are a customer of the project maintainer's commercial support company (and that fact is on the support company's website) and they submit high quality bug reports for vulnerabilities. What are we mad about again?

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

#447

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

I see you didn't read the article. The problem isn't Google reporting vulnerabilities. It's Google using AI to find obscure bugs that affect 2 people on the planet, then making a CVE out of it, without putting any effort into fixing it themselves or funding the project. What are the ffmpeg maintainers supposed to do about this? It's a complete waste of everybody's time. > The latest episode was sparked after a Google…

Close the bug, if they don’t care. They don’t want to do that because then people will yell at them for not caring.

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

#448

Earlier quoted context omitted.

Google is, at no cost to FFMPEG: 1) dedicating compute resources to continuously fuzzing the entire project 2) dedicating engineering resources to validating the results and creating accurate and well-informed bug reports (in this case, a seriously underestimated security issue) 3) additionally for codecs that Google likely does not even internally use or compile, purely for the greater good of FFMPEG's user base Nee…

FFMPEG, at no cost to Google, provided a core piece of their infrastructure for multiple multi-billion dollar product lines.

And this is why Google contributes back.

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

#449

They should set up a foundation/LLC if they don't have one already and require a support contract for fixing any bugs in niche codecs. Target the 95%-98% use cases for "free" work. If someone gives them a CVE on something ancient, just note it with an issue tracker and that the problem is currently unsponsored. Have default build flags to omit all the ancient/buggy stuff. If nobody is willing to pay to fix all the an…

https://fflabs.eu

Edit: Notably, Google is a paying client of FFmpeg's consulting entity.

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

#450
post #266
post #185

Earlier quoted context omitted.

Where do you draw the line? Do you want Google to just not inspect any projects that it can't fully commit to maintaining? Providing a real CVE is a contribution, not a burden. The ffmpeg folks can ignore it, since by all indications it's pretty minor.

What is the mission of Project Zero? Is it to build a vulnerability database, or is it to fix vulnerabilities? If it's to fix vulnerabilities, it seems within reason to expect a patch. If the reason Google isn't sending a patch is because they truly think the maintainers can fix it better, then that seems fair. But if Google isn't sending a patch because fixing vulns "doesn't scale" then that's some pretty weak sauce…

Project Zero is an offensive security team. Its job is to find vulnerabilities.
Post reply on HN