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…
FFmpeg to Google: Fund us or stop sending bugs
291–300 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#292Earlier 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#293Earlier 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.
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
#294Earlier 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
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
#295Earlier 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…
Re: FFmpeg to Google: Fund us or stop sending bugs
#296Earlier 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.
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
#297Here'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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#298Earlier 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.
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
#299Earlier quoted context omitted.
Google is a major contributor to open-source video, to the point where it would not be viable without them.
[flagged]
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
#300Earlier 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…
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 ?