From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…
Google is not paying anyone to find bugs. They are running AIs indiscriminately.
FFmpeg to Google: Fund us or stop sending bugs
131–140 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#132Re: FFmpeg to Google: Fund us or stop sending bugs
#133Earlier quoted context omitted.
On the other hand as an ffmpeg user do you care? 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? I mean someone could already be using the vulnerability regardless of what Google does.
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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#134Wouldn't they just fork it, fix their own bugs and stop contributing at all?
If you're going to fix the bug, why not in the main project?
Any time I have tried to fix a bug in an open source project I was immediately struck down with abusive attitudes about how I didn't do something exactly the way they wanted it that isn't really documented.
If that's what I have to expect, I'd rather not even interact with them at all.
Re: FFmpeg to Google: Fund us or stop sending bugs
#135A bunch of people who make era-defining software for free. A labor of love. Another bunch of people who make era-defining software where they extract everything they can. From customers, transactionally. From the first bunch, pure extraction (slavery, anyone?).
Irrespective of what Google does, security research is still useful for all of us. They could adopt a more flexible policy for FOSS though.
It's as useful as brute forcing one of your neighbor's 100 online passwords every day and writing it on the door of a random supermarket.
Re: FFmpeg to Google: Fund us or stop sending bugs
#136Earlier quoted context omitted.
How could ffmpeg maintainers kill three major AWS product lines with an email?
I'd guess Prime Video heavily relies on ffmpeg, then you got Elastic Transcode and the Elemental Video Services. Probably Cloudfront also has special things for streaming that rely on ffmpeg. The "kill it with an email" probably means that whoever said this is afraid that some usecase there wouldn't stand up to an audit by the usual patent troll mothercluckers. The patents surrounding video are so complex, old and pl…
AWS MediaConvert as well which is a huge API (in surface it covers) which is under Elemental but is kinda it's own thing - willing to bet (though I don't know) that that is ffmpeg somewhere underneath.
The API manual for it is nearly 4000 pages and it can do insane stuff[1].
I had to use it at last job(TM), it's not terrible API wise.
[1] https://docs.aws.amazon.com/pdfs/mediaconvert/latest/apirefe... CAUTION: big PDF.
Re: FFmpeg to Google: Fund us or stop sending bugs
#137Earlier quoted context omitted.
It’s not bug reports. It’s CVE. There is a convergence of very annoying trends happening: more and more are garbage found and written using AI and with an impact which is questionable at best, the way CVE are published and classified is idiotic and platform founding vulnerability research like Google are more and more hostile to projects leaving very little time to actually work on fixes before publishing. This is le…
CVEs aren't caused by bugs?
They are not published in project bug trackers and are managed completely differently so no, personally, I don't view CVE as bug reports. Also, please, don't distrort what I say and omit part of my comment, thank you.
Some of them are not even bugs in the traditional sense of the world but expected behaviours which can lead to unsecure side effects.
Re: FFmpeg to Google: Fund us or stop sending bugs
#138Earlier quoted context omitted.
If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.
So your claim is that buggy software is better than documented buggy software?
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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#139The vulnerability in question is a Use After Free. Google used AI to find this bug, it would've taken them 3 seconds to fix it. Burning cash to generate spam bug reports to burden volunteer projects when you have the extra cash to burn to just fix the damn issue leaves a very sour taste in my mouth.
Notably, the vulnerability is also in a part which isn't included by default and nobody uses. I'm not sure that even warrants a CVE? A simple bug report would have probably been fine. If they think this is really a CVE, a bug fix commit would have been warranted.
One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue.
That's the difference between "it may or may not be that there's someone who cares" versus "no one should be running this software anywhere in the general vicinity of untrusted inputs".
Re: FFmpeg to Google: Fund us or stop sending bugs
#140What is the point of Google's Project Zero? I'm not being dismissive. I understand the imperetive of identifying and fixing vulnerabilities. I also understand the detrimental impact that these problems can potentially have on Google. What I don't understand is the choice to have a public facing project about this. Can anyone shine a light on this?
I would imagine it's mostly a PR/marketing thing. That way the researchers can point to being part of something other people know about, and Google gets positive PR (though maybe not in this case) for spending resources on making software in general more secure.