Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

221–230 of 913 posts

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

#221

Earlier quoted context omitted.

> Google found a bug That does not impact their business or their operations in any way whatsoever. > If it's a valid bug then it's a valid bug end of story. This isn't a binary. It's why CVEs have a whole sordid scoring system to go along with them. > Software owes it to its users to be secure ffmpeg owes me nothing. I haven't paid them a dime.

> That does not impact their business or their operations in any way whatsoever. I don't know what tools and backends they use exactly, but working purely by statistics, I'm sure some place in Google's massive cloud compute empire is relying on ffmpeg to process data from the internet.

And they're processing old LucasArts codec videos with it? Which is the specific bug report in question.

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

#222
post #133
post #76

Earlier quoted context omitted.

This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it. In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix

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 Google can find it, so can others.

While true, Only Google has google infrastructure, this presupposes that 100% of all published exploits would be findable.

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

#223
post #174

Earlier quoted context omitted.

They are not published in project bug trackers and are managed completely differently so no, personally, I don't view CVE as bug reports . Also, please, don't distrort what I say and omit part of my comment, thank you. Some of them are not even bugs in the traditional sense of the world but expected behaviours which can lead to unsecure side effects.

It seems like you might misunderstand what CVEs are? They're just identifiers. This was a bug, which caused an exploitable security vulnerability. The bug was reported to ffmpeg, over their preferred method for being notified about vulnerabilities in the software they maintain. Once ffmpeg fixed the bug, a CVE number was issued for the purpose of tracking (e.g. which versions are vulnerable, which were never vulnerab…

I'm not misunderstanding anything. CVE involves a third party and it's not just a number. It's a number and an evaluation of severity.

Things which are usually managed inside a project now have a visibility outside of it. You might justify it as you want like the need to have an identifier. It doesn't fundamentally change how that impacts the dynamic.

Also, the discussion is not about a specific bug. It's a general discussion regarding how Google handles disclosure in the general case.

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

#224

Earlier quoted context omitted.

> Google found a bug That does not impact their business or their operations in any way whatsoever. > If it's a valid bug then it's a valid bug end of story. This isn't a binary. It's why CVEs have a whole sordid scoring system to go along with them. > Software owes it to its users to be secure ffmpeg owes me nothing. I haven't paid them a dime.

> ffmpeg owes me nothing. I haven't paid them a dime. That is true. At the same time Google also does not owe the ffmpeg devs anything either. It applies both ways. The whole "pay us or we won't fix this" makes no sense.

> Google also does not owe the ffmpeg devs anything either.

Then they can stop reporting bugs with their assinine one size fits all "policy." It's unwelcome and unnecessary.

> It applies both ways.

The difference is I do not presume things upon the ffmpeg developers. I just use their software.

> The whole "pay us or we won't fix this" makes no sense.

Pay us or stop reporting obscure bugs in unused codecs found using "AI" scanning, or at least, if you do, then change your disclosure policy for those "bugs." That's the actual argument and is far more reasonable.

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

#225
They should set up a foundation/LLC if they don't have one already and require a support contract for fixing any bugs in niche codecs. Target the 95%-98% use cases for "free" work. If someone gives them a CVE on something ancient, just note it with an issue tracker and that the problem is currently unsponsored. Have default build flags to omit all the ancient/buggy stuff. If nobody is willing to pay to fix all the ancient crap, then nobody should be using it. But if someone is willing to pay, then it gets fixed.

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

#226
post #80

Earlier quoted context omitted.

Notably, the vulnerability is also in a part which isn't included by default and nobody uses. I'm not sure that even warrants a CVE? A simple bug report would have probably been fine. If they think this is really a CVE, a bug fix commit would have been warranted.

One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue. That's the difference between "it may or may not be that there's someone who cares" versus "no one should be running this software anywhere in the general vicinity of untrusted inputs".

> One problem here is that CVE scoring is basically entirely bugged, something scored 8.7 could be an RCE exploit or a "may be able to waste CPU" issue.

+100000

My favorite 8.x or higher CVEs are the ones where you would have to take untrusted user input, bypass all the standard ways to ingest and handle that type of data, and pass it into some internal function of a library. And then the end result is that a regex call becomes more expensive.

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

#227
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.

AGPL, with no CLA that lets the owners relicense. Then we'll see if the using corporation fully believes in open source.

There's a reason Google turned into year 2000 Microsoft "it's viral!" re. the AGPL. They're less able to ignore the intent of the license and lock away their changes.

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

#228

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

Unfortunately, nobody not on Twitter can see anything except the first message, which just appears to be some corporate-deflection-speak.

It’s a trillion dollar company. I’m sure they could find rifle through their couch cushions and find more than enough money and under-utilised devs to contribute finance or patches.

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

#229

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…

I see you didn't read the article.

The problem isn't Google reporting vulnerabilities. It's Google using AI to find obscure bugs that affect 2 people on the planet, then making a CVE out of it, without putting any effort into fixing it themselves or funding the project. What are the ffmpeg maintainers supposed to do about this? It's a complete waste of everybody's time.

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

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

#230

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

Nice to see coming from Google. Some other current and form Google employees were unfortunately not as professional in their interactions on Twitter in regards to this issue.
Post reply on HN