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.
FFmpeg to Google: Fund us or stop sending bugs
201–210 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#202Earlier quoted context omitted.
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 it is so easy to fix, then why doesn't Google fix it? So far they've spent more effort in spreading knowledge about the vulnerability than fixing it, so I don't agree with your assessment that Google is not actively making the world worse here.
If you want to fix up old codecs in ffmpeg for fun, would you rather have a list of known broken codecs and what they're doing wrong; or would you rather have to find a broken codec first.
Re: FFmpeg to Google: Fund us or stop sending bugs
#203FFmpeg should just dual license at this point. If you're wanting shit fixed. You pay for it (based on usage) or GTFO. Should solve all of the current issues around this.
I absolutely understand the issue that a filthy-rich company tries to leech off of real unpaid humans. I don't understand how that issue leads to "GTFO, we won't fix these bugs". That makes no sense to me.
Re: FFmpeg to Google: Fund us or stop sending bugs
#204FFmpeg should stop fixing security bugs reported by Google, MS, Amazon, Meta etc. and instead wait for security patches from them. If FFmpeg maintainers will leave it exposed, those companies will rush to fixing it, because they'd be screwed otherwise. Every single one of them is dependent on FFmpeg exactly as shown in https://xkcd.com/2347/
I still fail to see why "ffmpeg is not allowed to fix bugs reported by corporations" is a good strategy. To me this sounds not logical.
Re: FFmpeg to Google: Fund us or stop sending bugs
#205Earlier quoted context omitted.
AIUI, (lib)ffmpeg is used by practically everything that does anything with video, including such definitely-security-sensitive things as Chrome, which people use to play untrusted content all the time.
Then maybe the Google chrome devs should submit a PR to ffmpeg.
Re: FFmpeg to Google: Fund us or stop sending bugs
#206Re: FFmpeg to Google: Fund us or stop sending bugs
#207Earlier quoted context omitted.
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.
For instance, I reported to the xorg-bug tracker that one app behaved oddly when I did --version on it. I was batch-reporting all xorg-applications via a ruby script.
Alan Coopersmith, the elderly hero that he is, fixed this not long after my report. (It was a real bug; granted, a super-small one, but still.)
I could give many more examples here. (I don't remember the exact date but I think I reported this within the last 3 years or so. Unfortunately reporting bugs in xorg-apps is ... a bit archaic. I also stopped reporting bugs to KDE because I hate bugzilla. Github issues spoiled me, they are so easy and convenient to use.)
Re: FFmpeg to Google: Fund us or stop sending bugs
#208> “The position of the FFmpeg X account is that somehow disclosing vulnerabilities is a bad thing. Google provides more assistance to open source software projects than almost any other organization, and these debates are more likely to drive away potential sponsors than to attract them.” This position likely to drive away maintainers. Generally the maintainers need these projects less than the big companies that use…
Re: FFmpeg to Google: Fund us or stop sending bugs
#209I’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…
> But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it I think this is the heart of the issue and it boils off all of the unimportant details. If it's a real, serious issue, you want to know about it and you want to fix it. Regardless of who reports it. If it's a real, but unimportant issue, you probably at least want to track it, but are…
[0] More or less. It seems the actual language is shied from. Is there a meaningful difference?
Re: FFmpeg to Google: Fund us or stop sending bugs
#210Earlier 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.
> 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? Yes? It's in the license > NO WARRANTY > 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANT…
Google should provide a fix but it's been standard to disclose a bug after a fixed time because the lack of disclosure doesn't remove the existence of the bug. This might have to be rethought in the context of OSS bugs but an MIT license shouldn't mean other people can't disclose bugs in my project.