Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

341–350 of 913 posts

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

#341

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…

From TFA:

> The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.”

This doesn't feel like a medium-severity bug, and I think "Perhaps reconsider the severity" is a polite reading. I get that it's a bug either way, but this leaves me with a vague feeling of the ffmpeg maintainer's time being abused.

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

#342
It'd be a silly license or condition, but, a license that says employees of companies in the S&P500 cant file bugs without an $X contribution, and cant expect a response in under Y days without a larger one, would be a funny way to combat it. Companies have no problem making software non-free or AGPL when it becomes inconvenient so maybe they can put up or shut up.

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

#343

Earlier quoted context omitted.

Easy: ffmpeg discontinues or relicenses some ffmpeg functionality that AWS depends on for those product alines and AWS is screwed. I've seen that happen in other open source projects.

But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.

something more dangerous would be "amazon is already breaking the license, but the maintainers for now havent put in the work to stop the infringement"

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

#344
post #266

Earlier quoted context omitted.

What is the mission of Project Zero? Is it to build a vulnerability database, or is it to fix vulnerabilities? If it's to fix vulnerabilities, it seems within reason to expect a patch. If the reason Google isn't sending a patch is because they truly think the maintainers can fix it better, then that seems fair. But if Google isn't sending a patch because fixing vulns "doesn't scale" then that's some pretty weak sauce…

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.

The ffmpeg authors aren't "shipping" anything; they're giving away something they make as a hobby with an explicit disclaimer of any kind of fitness for purpose. If someone needs something else, they can pay an engineer to make it for them.

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

#345
post #289

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…

Sure, it's a valid bug report. But I don't understand why there has been so much drama over this when all the ffmpeg folks have to do is say "sorry, this isn't a priority for us so we'll get to it as soon as we can" and put the issue in the backlog as a low priority. If Google wants the issue fixed faster, they can submit a fix. If they don't care enough to do that, they can wait. No big deal either way. Instead, ffmpeg is getting into a public tiff with them over what seems to be a very easily handled issue.

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

#346
post #289

Earlier quoted context omitted.

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…

Ffmpeg makes it trivial to enable and disable individual codecs at compile time. Perhaps it's the Linux distros that need to make a change here?

I get that the ffmpeg people have limited time and resources, I get that it would be nice if Google (or literally anyone else) patched this themselves and submitted that upstream. But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. If this is so obscure of a bug that there's no real risk, then there's no need for anyone to worry that the bug has been reported and will be publicized. On the other hand, if it's so dangerous that everyone should be rebuilding ffmpeg from source and compiling it out, then it really needs to be fixed in the up stream.

Edit: And also, how is anyone supposed to know they should compile the codec our unless someone makes a bug report and makes it public in the first place?

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

#347
post #9

Google might be aiming to replace ffmpeg as the world's best media professor. Remember how Jia Tan (under different names) flooded xz with work before stepping up as a maintainer.

Google, through YouTube and YouTube TV, already runs one of the most significant video processing lines of business in the world. If they had any interest in supplanting FFmpeg with their own software stack, they wouldn't need to muck around with CVEs to do so.

Not for themselves, but for everyone else for some reason.

Though it's more likely there's just some team tasked with shoving AI into vulnerability hunting.

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

#348

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.

I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another. "obscurity isn't security" is true enough, as far as it goes, but is just not that far. And "put the bugs that won't be fixed s…

The bug exists whether it's reported to the maintainers or not, so yeah, it's pretty naive.

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

#349
The message sounds like a human warning of someone is being fed-up with feeling taken advantage of. They see the profit being made, and they're not even getting drops of it.

If this isn't addressed, it makes this repo a target for actors that don't care about the welfare of Amazon, Google etc.

It seems quite predictable that someone will see this as a human weakness and try to exploit it, my question is whether we'll get them the support they need before the consequence hits, or whether we'll claim this was a surprise after the fact.

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

#350
post #63

Fully on FFmpeg team side, many companies approach to FOSS is only doing so when it sounds good on their marketing karma, leech otherwise. Most of them would just pirate in the old days, and most FOSS licences give them clear conscience to behave as always.

This is why many have warned against things like MIT licence. Yes, it gives you source code and does easily get incorporated into a lot of projects but it comes at the cost of potential abuse. Yes, GPL 3 is a lot ideologically but it was trying to limit excessive leeching. Now that I have opened the flood gates of a 20 year old debate, time to walk away.

There is nothing whatsoever that the GPL would do to change this situation. Bringing up the permissive license debate is a non-sequitur here.
Post reply on HN