Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

531–540 of 913 posts

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

#531
post #78

Earlier quoted context omitted.

> That is standard practice. It's standard practice for commercially-sponsored software, and it doesn't necessarily fit volunteer maintained software. You can't have the same expectations.

Vulnerabilities should be publicly disclosed. Both closed and open source software are scrutinized by the good and the bad people; sitting on vulnerabilities isn't good. Consumers of closed source software have a pretty reasonable expectation that the creator will fix it in a timely manner. They paid money, and the (generally) the creator shouldn't put the customer in a nasty place because of errors. Consumers of ope…

why are the standards and expectation different for google vs an independent researcher? Just because they are richer, doesn't mean they should be held to a standard that isn't done for an independent researcher.

The OSS maintainer has the responsibility to either fix, or declare they won't fix - both are appropriate actions, and they are free to make this choice. The consumer of OSS should have the right to know what vulns/issues exist in the package, so that they make as informed a decision as they can (such as adding defense in depth for vulns that the maintainers chooses not to fix).

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

#532
post #354

Earlier quoted context omitted.

If you are deliberately shipping insecure software, you should stop doing that. In ffmpeg's case, that means either patching the bug, or disabling the codec. They refused to do the latter because they were proud of being able to support an obscure codec. That puts the onus on them to fix the bug in it.

I can tell you with 100% certainty that there are undiscovered vulnerabilities in the Linux kernel right now. Does that mean they should stop shipping? I do think that contributing fuzzing and quality bug reports can be beneficial to a project, but it's just human nature that when someone says "you go ahead and do the work, I'll stand here and criticize", people get angry. Rather than going off and digging up ten tim…

>If Google really wants to improve the software quality of the open source ecosystem, the best thing they could do is solve the funding problem.

Google is not a monolith. If you asked the board, or the shareholders of google what they thought of open source software quality they would say they don't give a rat's ass about it. Someone within google who does care has been given very limited resources to deal with the problem, and are approaching it in the most efficient way they can.

>it's just human nature that when someone says "you go ahead and do the work, I'll stand here and criticize", people get angry

Bug reports are not criticism, they are in fact contributions, and the human thing to do when someone contributes to your project is to thank them.

>This is a company that takes a lot of pride in being the absolute best of the best.

There was an era when people actually believed that google was the best of the best, rather than saying it as a rhetorical trick, and during that era they never would have dreamed of making such self centered demands of google. This project zero business comes across as the last vestige of a dying culture within google. Why do people feel the need to be so antagonitic towards it?

>I can tell you with 100% certainty that there are undiscovered vulnerabilities in the Linux kernel right now. Does that mean they should stop shipping?

Hence why I qualified "deliberately".

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

#533

Earlier quoted context omitted.

A request to fix it would be privately telling the maintainers about the issue. Publicly releasing it is a demand.

This is not how filing issues against open source software works.

You dont get to decide that lmao. Telling everyone this project doesnt care about security if they ignore my CVE is obviously a demand and your traditions can not change that

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

#534

Earlier quoted context omitted.

There's no exploit on the bug report at least, unless you consider the crash reproducer one.

UAF bugs lead to RCE exploit chains.

They can if someone manages to develop an exploit. Let's not confuse vulnerabilities and exploits.

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

#535

Earlier quoted context omitted.

More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place. Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have th…

The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.

There is no "the bug". The discussion is about what to do with the power of bug-finding tools.

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

#536

Here'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

If you rely on it, pay for it. So easy. Especially if you are a BIIG company. Money gives the maintainers joy, free time and appreciation for their work.

Wakey wakey people, FOSS is here to F you. It can be free, while those, who rely on it and using it, also pay for it.

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

#537
post #323

Earlier quoted context omitted.

I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…

As yet, Valve is the only company I know of doing this, and it's paying off in dividends both for Linux and for Valve. In just 5ish years of Valve investing people and money into Linux- specifically mesa and WINE, Linux has gone from a product that is kind of shaky with Windows, to "I can throw a windows program or game at it and it usually works". Imagine how further the OSS ecosystem would be if Open Source hadn't…

They totally broke CSGO Legacy's code to push its sequel CS2 and won't accept fixes for it because it's 'not being supported'.

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

#538
post #500
post #472

Earlier quoted context omitted.

If widely deployed infrastructure software is so full of vulnerabilities that its maintainers can't fix them as fast as they're found, maybe it shouldn't be widely deployed, or they shouldn't be its maintainers. Disabling codecs in the default build that haven't been used in 30 years might be a good move, for example. Either way, users need to know about the vulnerabilities. That way, they can make an informed tradeo…

> they shouldn't be its maintainers. I mean, yes, the ffmpeg maintainers are very likely to decide this on their own, abandoning the project entirely. This is already happening for quite a few core open source projects that are used by multiple billion-dollar companies and deployed to billions of users. A lot of the projects probably should be retired and rewritten in safer system languages. But rewriting all of the…

> abandoning the project entirely

that is a good outcome, because then the people dependent on such a project would find it plausible to pay a new set of maintainers.

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

#539

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

I've grown a bit disillusioned with contributing to Github. I've said this on here before, but a few months ago I wrote a simple patch for LMAX Disruptor, which was merged in. I like Disruptor, it's a very neat library, and at first I thought it was super cool to have my code merged. But after a few minutes, I started thinking: I just donated my time to help a for-profit company make more money. LMAX isn't a charity,…

I understand the feeling. There is a huge asymmetry between individual contributors and huge profitable companies.

But I think a frame shift that might help is that you're not actually donating your time to LMAX (or whoever). You're instead contributing to make software that you've already benefited from become better. Any open source library represents many multiple developer-years that you've benefited from and are using for free. When you contribute back, you're participating in an exchange that started when you first used their library, not making a one-way donation.

> They wouldn't have merged my code in if they didn't think it had some amount of value, and if they think it has value then they should pay me.

This can easily be flipped: you wouldn't have contributed if their software didn't add value to your life first and so you should pay them to use Disruptor.

Neither framing quite captures what's happening. You're not in an exchange with LMAX but maintaining a commons you're already part of. You wouldn't feel taken advantage of when you reshelve a book properly at a public library so why feel bad about this?

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

#540
post #443

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

Given that Google is both the company generating the bug reports and one of the companies using the buggy library, while most of the ffmpeg maintainers presumably aren't using their libraries to run companies with a $3.52 trillion dollar market cap, would you argue that going public with vulnerabilities that affect your own product before you've fixed them is also a naive approach?

Sorry, but this states a lot of assumption as fact to ask a question which only makes sense if it's all true. I feel Google should assist the project more financially given how much they use it, but I don't think Google shipping products using every codec they find bugs for with their open source fuzzer project is a reasonable guess. I certainly doubt YouTube/Chrome let's you upload/compiles ffmpeg with this LucasArts format, as an example. For security issues relevant to their usage via Chrome CVEs etc, they seem to contribute on fixes as needed. E.g. here is one via fuzzing or a codec they use and work on internally https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb...

In regards whether it's a bad idea to publicly document security concerns found regardless whether you plan on fixing them, it often depends if you ask the product manager what they want for their product or what the security concerned folks in general want for every product :).

Post reply on HN