Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

201–210 of 913 posts

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

#201

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.

In general it is not good when companies get too much power. See how shopify is eating away the ruby infrastructure right now after RubyCentral panicked when shopify blackmailed the community by taking away funding. Of course it is their money, but the whole ecosystem suddenly submitting to one huge company, really really sucks to no ends. Hobbyists are at the weakest here.

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

#202
post #180
post #133

Earlier 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.

I didn't say it was easy to fix. I said a publication made it easy to find it, if someone wanted to fix something.

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

#203

FFmpeg 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.

You mean, Google reports a bug, and ffmpeg devs say "GTFO"? Let's assume this is a real bug: is that what you would the ffmpeg developers to say to Google?

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

#204

FFmpeg 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 understand the problem of corporations leeching off of the community here.

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

#205

Earlier 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.

Sure. And fund them.

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

#207
post #102

Earlier 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.

I don't think this is what typically happens. Many of my bug reports were handled.

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…

I doubt there's an endgame in mind. It's probably small teams trying to optimize their quarterly KPIs

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

#209

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…

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

But if it's a real, serious issue without an easy resolution, who is the burden on? It's not that the maintainers wouldn't fix bugs if they easily could. FFmpeg is provided "as is"[0], so everyone should be responsible for their side of things. It's not like the maintainers dumped their software on every computer and forced people to use it. Google should be responsible for their own security. I'm not adamant that Google should share the patch with others, but it would hardly be an imposition to Google if they did. And yes, I really do intend that you could replace Google with any party, big or small, commercial or noncommercial. It's painful, but no one has any inherent obligations to provide others with software in most circumstances.

[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

#210

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

Not being told the existence of bugs is different from having a warranty on software. How would you submit a patch on a bug you were not aware of?

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.

Post reply on HN