FFmpeg to Google: Fund us or stop sending bugs

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 perfectly fine (it’s okay for projects to decide that security isn’t a priority!), but you can’t have it both ways.

My takeaway from the article was not that the report was a problem, but a change in approach from Google that they’d disclose publicly after X days, regardless of if the project had a chance to fix it.

To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’m sure you better than me, that that’s not who volunteering works

That is standard practice. It is considered irresponsible to not publicly disclose any vulnerability.

The X days is a concession to the developers that the public disclosure will be delayed to give them an opportunity to address the issue.

Here's the question:

Why is Google deliberately running an AI process to find these bugs if they're just going to dump them all on the FFmpeg team to fix?

They have the option to pay someone to fix them.

They also have the option to not spend resources finding the bugs in the first place.

If they think these are so damn important to find that it's worth devoting those resources to, then they can damn well pay for fixing them too.

Or they can shut the hell up and let FFmpeg do its thing in the way that has kept it one of the https://xkcd.com/2347/ pieces of everyone's infrastructure for over 2 decades.

I would love to see Google contribute here, but I think that's a different issue.

Are the bug reports accurate? If so, then they are contributing just as if I found them and sent a bug report, I'd be contributing. Of course a PR that fixes the bug is much better than just a report, but reports have value, too.

The alternative is to leave it unfound, which is not a better alternative in my opinion. It's still there and potentially exploitable even when unreported.

But FFmpeg does not have the resources to fix these at the speed Google is finding them.

It's just not possible.

So Google is dedicating resources to finding these bugs

and feeding them to bad actors.

Bad actors who might, hypothetically have had the information before, but definitely do once Google publicizes them.

You are talking about an ideal situation; we are talking about a real situation that is happening in the real world right now, wherein the option of Google reports bug > FFmpeg fixes bug simply does not exist at the scale Google is doing it at.

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 tradeoff between, for example, disabling the LucasArts Smush codec in their copy of ffmpeg, and being vulnerable to this hole (and probably many others like it).

> 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 widely-used projects suffering from these issues would likely cost hundreds of millions of dollars.

The alternative is that maybe some of the billion-dollar companies start making lists of all the software they ship to billions of users, and hire some paid maintainers through the Linux or Apache Foundations.

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