Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

Post reply on HN
Print view View original

631–640 of 913 posts

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

#631

Post by walletdrainer »

SpicyLemonZest wrote: post #58
Lerc wrote: 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.

The entire conflict here is that norms about what's considered responsible were developed in a different context, where vulnerability reports were generated at a much lower rate and dedicated CVE-searching teams were much less common. FFmpeg says this was "AI generated bug reports on an obscure 1990s hobby codec"; if that's accurate (I have no reason to doubt it, just no time to go check), I tend to agree that it doe…

> CVE-searching teams

Silly nitpick, but you search for vulnerabilities not CVEs. CVE is something that may or may not be assigned to track a vulnerability after it has been discovered.

Most security issues probably get patched without a CVE ever being issued.

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

#632

Post by pjc50 »

gowld wrote: post #252
janalsncm wrote: post #242

Earlier quoted context omitted.

All the license means is that I can’t sue them. It doesn’t mean I have to like it. Just because software makes no guarantees about being safe doesn’t mean I want it to be unsafe.

If the software makes no guarantees about being safe, then you should assume it is unsafe.

OK, then you can't decode videos.

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

#633

Post by walletdrainer »

danaris wrote: post #247
freedomben wrote: post #152

Earlier quoted context omitted.

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 an…

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 t…

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

Google submitting a patch does not address this issue. The main work for maintainers here is making the decision whether or not they want to disable this codec, whether or not Google submits a patch to do that is completely immaterial.

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

#634

Post by izacus »

lodovic wrote: post #545
rossjudson wrote: post #451

Earlier quoted context omitted.

I'm glad you threw in "I know of", because that part is true. Feel free to read lore.kernel.org, and sort out where the people contributing many patches actually work.

Can't you just give the information you are hinting at? Other people than OP read this. You basically tell me to go read thousands of messages on a mailing list just solve your rhetorical question. (answer: Intel, Redhat, Meta, Google, Suse, Arm and Oracle. There are much more efficient ways to find this.) Yes, they are the main kernel contributors and have been for many years. I'm still not sure I understand the com…

No, "just" having to debunk BS from a BSer who lazily threw out misinformation is not the way to go. It's the BSer that needs to do more work.

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

#635

Post by Dylan16807 »

khannn wrote: post #444
saagarjha wrote: post #430

Earlier quoted context omitted.

Publishing bugs that the project has so that they can be fixed is actively making the project more secure. How is someone going to do anything about it if Google didn’t do the research?

Did you see how the FFMPEG project patched a bug for a 1995 console? That's not a good use for the limited amount of volunteers on the project. It actively makes it less secure by taking away from more pertinent bugs.

If it was a rendering bug it would be a waste of time. But they also wouldn't have any pressure to fix it.

An exploit is different. It can affect anyone and is quite pertinent.

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

#636

Post by walletdrainer »

HDThoreaun wrote: post #370
ikiris wrote: 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.

CVE!=vulnerability

These two terms are not interchangeable.

Most vulnerabilities never have CVEs issued.

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

#637

Post by lm28469 »

profsummergig wrote: post #511
Aurornis wrote: post #476

Earlier quoted context omitted.

> (slavery, anyone?) It’s hard to take any comment seriously that tries to use “slavery” for situations where nobody is forced to do anything for anyone.

[flagged]

No we can't use such strong words here, theft is more appropriate

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

#638

Post by zgk7iqea »

u_sama wrote: post #621
nektro wrote: post #603

FFmpeg is a great project but their twitter is embarrassing and should not be news

Why, their Twitter seems reasonable and combative towards companies who want to exploit their results without contribution ?

google is a customer of fflabs and has enrolled them in summer of code. They also provide free fuzzing. ffmpeg is a foss, gpl-licensed project. nobody has any obligation to contribute, thus it isn't exploitation.

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

#639

Post by surajrmal »

Root_Denied wrote: post #558
rossjudson wrote: post #451

Earlier quoted context omitted.

I'm glad you threw in "I know of", because that part is true. Feel free to read lore.kernel.org, and sort out where the people contributing many patches actually work.

I'd say as a counterpoint that just because someone works at, say, Meta or Oracle, and also contributes to OSS projects, that doesn't equate to the company they work at funding upstream projects (at least not by itself). I don't even have to link the xkcd comic because everyone already knows which one goes here.

Everyone I know who contributes to Linux upstream is paid to do it. It's not really worth the hassle to bother trying if you weren't getting paid. It's also very easy to find companies that will pay you to work on Linux and upstream.

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

#640

Post by walletdrainer »

bragr wrote: post #352
xethos wrote: post #341

Earlier quoted context omitted.

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…

If it causes a crash, that's denial of service, so medium would be appropriate. But it's true that medium CVEs aren't that bad in most situations.

This bug can most likely lead to RCE, proving that it can’t is generally a very difficult problem.

There’s absolutely no reason to assume that it does not lead to RCE, and certainly no reason whatsoever to invest significant time to prove that one way or the other unless you make a living selling exploits.

Post reply on HN