Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

291–300 of 913 posts

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

#291
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…

If you are deliberately shipping insecure software, you should stop doing that. In ffmpeg's case, that means either patching the bug, or disabling the codec. They refused to do the latter because they were proud of being able to support an obscure codec. That puts the onus on them to fix the bug in it.

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

#292
post #182

Earlier quoted context omitted.

If they want that level of control, reimburse for all the prior development too. - ie: buy that business. As it stands, they're just abusing someone's gift. Like jerks.

There should be a "if you use this product in a for-profit environment, and you have a yearly revenue of $500,000,000,000+ ... you can afford to pay X * 100,000/yr" license.

There is also the AGPL.

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

#293
post #252

Earlier quoted context omitted.

All the license means is that I can’t sue them. It doesn’t mean I have to like it. Just because software makes no guarantees about being safe doesn’t mean I want it to be unsafe.

If the software makes no guarantees about being safe, then you should assume it is unsafe.

Anyone who has seen how the software is sausaged knows that. Security flaws will happen, no matter what the lawyers put in the license.

And still, we live in a society. We have to use software, bugs or not.

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

#294
post #285
post #262

Earlier quoted context omitted.

Sometimes it's hard: for many kinds of projects, I don't think anyone would use them if they were not open source (or at least source-available). Just like I wouldn't use a proprietary password manager, and I wouldn't use WhatsApp if I had a choice. Rather I use Signal because it's open source. How to get people to use your app if it's not open source, and therefore not free? For some projects, it feels better to hav…

You can just use the GPL, then it's free, but your labour cannot be so easily profited from by big corps

But it can be profited for not-so-big corps, so I'm still working for free.

Also I have never received requests from TooBigTech, but I've received a lot of requests from small companies/startups. Sometimes it went as far as asking for a permissive licence, because they did not want my copyleft licence. Never offered to pay for anything though.

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

#295

Earlier quoted context omitted.

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.

I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another. "obscurity isn't security" is true enough, as far as it goes, but is just not that far. And "put the bugs that won't be fixed s…

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

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

#296
post #133
post #76

Earlier quoted context omitted.

This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it. In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix

The user is vulnerable while the problem is unfixed. Google publishing a vulnerability doesn't change the existence of the vulnerability. If Google can find it, so can others. Making the vulnerability public makes it easy to find to exploit, but it also makes it easy to find to fix.

>If Google can find it, so can others.

What a strange sentence. Google can do a lot of things that nobody can do. The list of things that only Google, a handful of nation states, and a handful of Google-peers can do is probably even longer.

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

#297

Here's a thread by Google's head of security that notes the ways they've contributed to FFmpeg over the years: https://x.com/argvee/status/1986194852669964528

Unfortunately, nobody not on Twitter can see anything except the first message, which just appears to be some corporate-deflection-speak. It’s a trillion dollar company. I’m sure they could find rifle through their couch cushions and find more than enough money and under-utilised devs to contribute finance or patches.

Google is one of the largest contributors to OSS in the world, so they're already throwing literal millions at OSS?

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

#298

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…

Google is: - choosing to do this of their own volition - are effectively just using their resources to throw bug reports over the wall unprompted. - benefiting from the bugs getting fixed, but not contributing to them.

> - benefiting from the bugs getting fixed, but not contributing to them.

I would be very surprised if Google builds this codec when they build ffmpeg. If you run a/v codecs (like ffmpeg) in bulk, the first thing to do is sandbox the hell out of it. The second thing you do is strictly limit the containers and codecs you'll decode. Not very many people need to decode movies from old LucasArts games, for video codecs, you probably only want mpeg 1-4, h.26x, vp8, vp9, av1. And you'll want to have fuzzed those decoders as best you can too.

Nobody should be surprised that there's a security problem in this ancient decoder. Many of the eclectic codecs were written to mimic how the decoders that shipped with content were written, and most of those codecs were written assuming they were decoding a known good file, because why wouldn't they be. There's no shame, that's just how it is... there's too much to proactively investigate, so someone doing fuzzing and writing excellent reports that include diagnosis, specific location of the errors, and a way to reproduce are providing a valuable contribution.

Could they contribute more? Sure. But even if they don't, they've contributed something of value. If the maintainers can't or don't want to address it, that'd be reasonable too.

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

#299
post #188

Earlier quoted context omitted.

Google is a major contributor to open-source video, to the point where it would not be viable without them.

[flagged]

Look, I know you're being snarky, but YES. All of the viable open-source video codecs of the past 10 years would not have happened without Google. Not just for technical reasons, but for expensive patent-related legal reasons too.

Given that ffmpeg is an open-source video transcoding tool, I don't think you can easily just dismiss this as "big company abuses open source."

The ffmpeg devs are volunteers or paid to work on specific parts of the tool. That's why they're unimpressed. What Google is doing here is pretty reasonable.

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

#300

Earlier quoted context omitted.

I would love to see Google contribute here, but I think that's a different issue. Are the bug reports accurate? If so, then they are contributing just as if I found them and sent a bug report, I'd be contributing. Of course a PR that fixes the bug is much better than just a report, but reports have value, too. The alternative is to leave it unfound, which is not a better alternative in my opinion. It's still there an…

But FFmpeg does not have the resources to fix these at the speed Google is finding them. It's just not possible. So Google is dedicating resources to finding these bugs and feeding them to bad actors. Bad actors who might, hypothetically have had the information before, but definitely do once Google publicizes them. You are talking about an ideal situation; we are talking about a real situation that is happening in t…

A solution definitely ought to be found. Google putting up a few millionths of a percent of their revenue or so towards fixing the bugs they find in ffmpeg would be the ideal solution here, certainly. Yet it seems unlikely to actually occur.

I think the far more likely result of all the complaints is that Google simply completely disengages from ffmpeg and stops doing any security work on it. I think that would be quite bad for the security of the project - if Google can trivially find bugs at a high speed such that it overwhelms the ffmpeg developers, I would imagine bad actors can also search for them and find those same vulnerabilities Google is constantly finding, and if they know that those vulnerabilities very much exist, but that Google has simply stopped searching for them upon demand of the ffmpeg project, this would likely give them extremely high motivation to go looking in a place they can be almost certain they'll find unreported/unknown vulnerabilities in. The result would likely be a lot more 0-day attacks involving ffmpeg, which I do not think anyone regards as a good outcome (I would consider "Google publishes a bunch of vulnerabilities ffmpeg hasn't fixed so that everyone knows about them" to be a much preferable outcome, personally)

Now, you might consider that possibility fine - after all, the ffmpeg developers have no obligation to work on the project, and thus to e.g. fix any vulnerabilities in it. But if that's fine, then simply ignoring the reports Google currently makes is presumably also fine, no ?

Post reply on HN