Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

381–390 of 913 posts

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

#381

Post by thevillagechief »

XorNot wrote: post #269
esrauch wrote: post #118

Earlier quoted context omitted.

This program discloses security issues to the projects and only discloses them after they have had a "reasonable" chance to fix it though, and projects can request extensions before disclosure if projects plan to fix it but need more time. Google runs this security program even on libraries they do not use at all, where it's not a demand, it's just whitehat security auditing. I don't see the meaningful difference bet…

Google is a multi-billion dollar company, which is paying people to find these bugs in the first place. That's a pretty core difference.

Corporate Social Responsibility? The assumption is that the work is good for end users. I don't know if that's the case for the maintainers though.

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

#383

Post by tpmoney »

dotancohen wrote: post #340
inkysigma wrote: post #210

Earlier quoted context omitted.

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

Google publicly disclosing the bug doesn't only let affected users know. It also lets attackers know how they can exploit the software. Holding public disclosure over the heads of maintainers if they don't act fast enough is damaging not only to the project, but to end users themselves also. There was no pressing need to publicly disclose this 25 year old bug.

How is having a disclosure policy so that you balance the tradeoffs between informing people and leaving a bug unreported "holding" anything over the heads of the maintainers? They could just file public bug reports from the beginning. There's no requirement that they file non-public reports first, and certainly not everyone who does file a bug report is going to do so privately. If this is such a minuscule bug, then whether it's public or not doesn't matter. And if it's not a minuscule bug, then certainly giving some private period, but then also making a public disclosure is the only responsible thing to do.

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

#384

Post by ironman1478 »

shevy-java wrote: post #196
ironman1478 wrote: post #92

Never work for free. It's a complete market distortion and leads to bad actors taking advantage of you and your work.

That's fine. Are they required to work for Google? I mean, they are independent and can decide on their own.

Corporations extract a ton of value from projects like ffmpeg. They can either pay an employee to fix the issues or setup some sort of contract with members of the community to fix bugs or make feature enhancements.

There is precedent for this: https://sqlite.org/consortium.html

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

#385

Post by tpmoney »

XorNot wrote: post #269
esrauch wrote: post #118

Earlier quoted context omitted.

This program discloses security issues to the projects and only discloses them after they have had a "reasonable" chance to fix it though, and projects can request extensions before disclosure if projects plan to fix it but need more time. Google runs this security program even on libraries they do not use at all, where it's not a demand, it's just whitehat security auditing. I don't see the meaningful difference bet…

Google is a multi-billion dollar company, which is paying people to find these bugs in the first place. That's a pretty core difference.

Great, so Google is actively spending money on making open source projects better and more secure. And for some reason everyone is now mad at them for it because they didn't also spend additional money making patches themselves. We can absolutely wish and ask that they spend some money and resources on making those patches, but this whole thing feels like the message most corporations are going to take is "don't do anything to contribute to open source projects at all, because if you don't do it just right, they're going to drag you through the mud for it" rather than "submit more patches"

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

#386

Post by tpmoney »

necovek wrote: post #187
vadansky wrote: post #35

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.

As clearly stated, most users of ffmpeg are unaware of them using it. Even them knowing about a vulnerability in ffmpeg, they wouldn't know they are affected. Really, the burden is on those shipping products that depend on ffmpeg: they are the ones who have to fix the security issues for their customers. If Google is one of those companies, they should provide the fix in the given time.

But how are those companies supposed to know they need to do anything unless someone finds and publicly reports the issue in the first place? Surely we're not advocating for a world where every vendor downstream of the ffmpeg project independently discovers and patches security vulnerabilities without ever reporting the issues upstream right?

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

#387

Post by theoldgreybeard »

vsgherzi wrote: post #146

I understand ffmpeg being angry at the workload but this is how it is with large open source projects. Ffmpeg has no obligation to fix any of this. Open source is a gift and is provided as is. If Google demanded a fix I could see this being an issue. As it is right now it just seems like a bad look. If they wanted compensation then they should change the model, there's nothing wrong with that. Google found a bug, the…

> Software owes it to its users to be secure.

There is no such obligation.

There is no warranty and software is provided AS-IS explicitly by the license.

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

#388

Post by tpmoney »

EasyMark wrote: post #362
vadansky wrote: post #35

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.

I have about 100x as much sympathy for an open source project getting time to fix a security bug than I do a multibillion dollar company with nearly infinite resources essentially blackmailing a small team of developers like this. They could -easily- pay a dev to fix the bug and send the fix to ffmpeg.

Since when are bug reports blackmail? If some retro game enthusiast discovered this bug and made a blog post about it that went to the front page of HN, is that blackmail? If someone running a fuzzer found this bug and dumped a public bug report into github is that blackmail? What if google made this report privately, but didn't say anything about when they would make it public and then just went public at some arbitrary time in the future? How is "heads up, here's a bug we found, here's the reproduction steps for it, we'll file a public bug report on it soon" blackmail?

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

#389

Post by renhanxue »

jsnell wrote: post #289
michaelt wrote: post #282

Earlier quoted context omitted.

It's a good quality bug report. But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1] Pretty crazy that ffmpeg supports the codec in the first place, IMHO. I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't b…

It's a codec that is enabled by default at least on major Linux distributions, and that will be processed by ffmpeg without any extra flags. Anyone playing an untrusted video file without explictly overriding the codec autodetection is vulnerable. The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as t…

There are dozens if not hundreds of issues just like this one in ffmpeg, except for codecs that are infinitely more common. Google has been running all sorts of fuzzers against ffmpeg for over a decade at this point and it just never ends. It's a 20 year old C project maintained by poorly funded volunteers that mostly gives every media file ever the be-liberal-in-what-you-accept treatment, because people complain if it doesn't decode some bizarrely non-standard MPEG4 variant recorded with some Chinese plastic toy from 2008. Of course it has all of the out-of-bounds bugs. I poked around on the issue tracker for like 5 minutes and found several "high impact" issues similar to the one in TFA just from the last two or three months, including at least one that hasn't passed the 90 day disclosure window yet.

Nobody who takes security even remotely seriously should decode untrusted media files outside of a sandboxed environment. Modern media formats are in themselves so complex one starts wondering if they're actually Turing complete, and in ffmpeg the attack surface is effectively infinitely large.

The issue is CVE slop because it just doesn't matter if you consider the big picture.

Some example issues to illustrate my point:

https://issuetracker.google.com/issues/436511754 https://issuetracker.google.com/issues/445394503 https://issuetracker.google.com/issues/436510316 https://issuetracker.google.com/issues/433502298

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

#390

Post by rmunn »

ndriscoll wrote: post #356
rmunn wrote: post #268

Earlier quoted context omitted.

Have you ever used a piece of software that DID make guarantees about being safe? Every software I've ever used had a "NO WARRANTY" clause of some kind in the license. Whether an open-source license or a EULA. Every single one. Except, perhaps, for public-domain software that explicitly had no license, but even "licenses" like CC0 explicitly include "Affirmer offers the Work as-is and makes no representations or warr…

I don't know what our contract terms were for security issues, but I've certainly worked on a product where we had 5 figure penalties for any processing errors or any failures of our system to perform its actions by certain times of day. You can absolutely have these things in a contract if you pay for it, and mass market software that you pay for likely also has some implied merchantability depending on jurisdiction…

Point. As part of a negotiated contract, some companies might indeed put in guarantees of software quality; I've never worked in the nuclear industry or any other industries where that would be required, so my perspective was a little skewed. But all mass-distributed software I've ever seen or heard of, free or not, has that "no warranty" clause, and only individual contracts are exceptions.

Also, "depending on jurisdiction" is a good point as well. I'd forgotten how often I've seen things like "Offer not valid in the state of Delaware/California/wherever" or "If you live in Tennessee, this part of the contract is preempted by state law". (All states here are pulled out of a hat and used for examples only, I'm not thinking of any real laws).

Post reply on HN