Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

431–440 of 913 posts

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

#431

Is it unreasonable to ask that if a massive company funds someone to find a CVE in an open source project, they should also submit a patch? Google is a search company. Seems kind of... evil... to pay your devs to find holes in something with nothing to do with searching, then refuse to pay them to fix the problem they noticed.

Google contributes to ffmpeg on a fairly regular basis https://git.ffmpeg.org/gitweb/ffmpeg.git/search/HEAD?s=@goog...

No it's not "unreasonable" to ask for patches along with bug fixes, but it is unreasonable to be mad if they don't. They could just not file the bug reports at all, and that is an objectively worse outcome.

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

#434
post #432

[flagged]

why would you post such a patently absurd accusation.

I saw that tweet and thought it looked crazy. To me, it sounds like a death threat. Especially given that it's posted on X.com, after a really heated argument, with no clarification afterwards.

If you didn't actually post that tweet, that's great! I'm happy to be corrected

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

#435

Earlier quoted context omitted.

If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.

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…

It's a heck of a lot better than being unaware of it.

(To put this in context: I assume that on average a published security vulnerability is known about to at least some malicious actors before it's published. If it's published, it's me finding out about it, not the bad actors suddenly getting a new tool)

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

#436
post #219
post #60

Earlier quoted context omitted.

> 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. That is not an accurate description? Project Zero was using a 90 day disclosure policy from the start, so for over a decade. What changed[0] in 2025 is that they disclose earlier than 90 days that there is an issue ,…

The fact that details of the issue _will_ be disclosed publicly is an implicit threat. Sure it's not an explicit threat, but it's definitely an implicit threat. So the demand, too, is implicit: fix this before we disclose publicly, or else your vulnerability will be public knowledge.

You should not be threatened by the fact that your software has security holes in it being made public knowledge. If you are, then your goals are fundamentally misaligned with making secure software.

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

#437
post #339

Earlier quoted context omitted.

No, publishing the vulnerability is the right thing to do for a secure world because anyone can find this stuff including nation states that weaponize it. This is a public service. Giving the dev a 90 day pre warn is a courtesy. Expecting a reporter to fix your security vulnerabilities for you is entitlement. If your reputation is harmed by your vulnerable software, then fix the bugs. They didn’t create the hazzard t…

This is all true(maybe not the extortion being worse hard to say), but it doesnt change the fact that publishing the CVE is a demand to fix it.

No, it is a request to fix it. How the maintainer feels about it is up to them.

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

#438
post #78
post #42

Earlier quoted context omitted.

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.

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

This is standard practice for Linux as well.

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

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

Not really. It requires time, ergo money.

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

#440

Earlier quoted context omitted.

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, ffm…

FFMPEG is upset because Google made the exploit public. They preferred that it remained a zero-day until they decided it was a priority. I don't understand how anyone believes that behavior is acceptable.

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