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

641–650 of 913 posts

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

#641

Post by walletdrainer »

saagarjha wrote: post #445
lenerdenator wrote: post #284

Earlier quoted context omitted.

They aren't obligated to fix CVEs until they're exploited, and then, suddenly, they very much were obligated to fix the CVEs, and their image as FLOSS maintainers and as a project are very much tarnished.

If they are unable to fix CVEs in a timely manner, then it is very reasonable for people to judge them (accurately!) as being unable to fix CVEs in a timely manner. Maybe some people might even decide to use other projects or chip in to help out! However, it is dishonest to hide reports and pretend like bugs are being fixed on time when they are not.

Please don’t use “CVE” as a stand-in for “vulnerability”, you know much better than this :)

Most vulnerabilities never get CVEs even when they’re patched.

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

#642

Post by Dylan16807 »

samus wrote: post #617
chii wrote: post #531

Earlier quoted context omitted.

why are the standards and expectation different for google vs an independent researcher? Just because they are richer, doesn't mean they should be held to a standard that isn't done for an independent researcher. The OSS maintainer has the responsibility to either fix, or declare they won't fix - both are appropriate actions, and they are free to make this choice. The consumer of OSS should have the right to know wha…

They are different because the independent researchers don't make money off the projects that they investigate.

Google makes money off ffmpeg in general but not this part of the code. They're not getting someone else to write a patch that helps them make money, because google will just disable this codec if it wasn't already disabled in their builds.

Also in general Google does investigate software they don't make money off.

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

#643

Post by gnfargbl »

Y-bar wrote: post #324
gnfargbl wrote: post #251

Earlier quoted context omitted.

They could, but there is really no requirement on them to do so. The security flaw was discovered by Google, but it was not created by them. Equally there is no requirement on ffmpeg to fix these CVEs nor any other. And, of course, there is no requirement on end-users to run software from projects which do not consider untrusted-input-validation bugs to be high priority.

> They could, but there is really no requirement on them to do so. I see this sort of sentiment daily. The sentiment that only what is strictly legal or required is what matters. Sometimes, you know, you have to recognise that there are social norms and being a good person matters and has intrinsic value. A society only governed by what the written law of the land explicitly states is a dystopia worse than hell.

You're correct, but it's the social norms -- or at least, the norms as I perceive them -- that I am talking about here.

If you find yourself with potentially serious security bugs in your repo, then the social norm should be for you to take ownership of that because, well, it's your repo.

The socially unacceptable activity here should be treating security issues as an irritation, or a problem outside your control. If you're a maintainer, and you find yourself overwhelmed by genuine CVE reports, then it might be worth reflecting on the root cause of that. What ffmpeg did here was to shoot the messenger, which is non-normative.

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

#644

Post by codedokode »

fulafel wrote: post #534
iscoelho wrote: post #464

Earlier quoted context omitted.

UAF bugs lead to RCE exploit chains.

They can if someone manages to develop an exploit. Let's not confuse vulnerabilities and exploits.

This bug might lead to vulnerability and that's enough. It makes no sense to waste lot of time and research whether it is possible or not - it is faster to remove the buggy codec nobody needs or make a fix.

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

#645

Post by surajrmal »

renhanxue wrote: post #412
jsnell wrote: post #403

Earlier quoted context omitted.

I don't get why you think linking to multiple legitimate and high quality bug reports with detailed analysis and precise reproduction instructions demonstrates "slop". It is the opposite. This is software that is directly or indirectly run by millions of people on untrusted media files without sandboxing. It's not even that they don't care about security, it's that they're unaware that they should care. It should go…

All of these reports are effectively autogenerated by Big Sleep from fuzzing. Again, Google has been doing this sort of thing for over a decade and has found untold thousands of vulnerabilities like this one. It is not at all clear to me that their doing so has been all that valuable.

AI found the bug, but the analysis and bug report were entirely written by a human without AI assistance. Source: I work with the author.

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

#646

Post by walletdrainer »

V__ wrote: post #80
theoldgreybeard wrote: post #72

The vulnerability in question is a Use After Free. Google used AI to find this bug, it would've taken them 3 seconds to fix it. Burning cash to generate spam bug reports to burden volunteer projects when you have the extra cash to burn to just fix the damn issue leaves a very sour taste in my mouth.

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.

Not only is it included by default, but you can trigger this with a file that looks like a mp4 to the user.

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

#647

Post by walletdrainer »

ranger_danger wrote: post #22
StopDisinfo910 wrote: post #14

Earlier quoted context omitted.

It’s not bug reports. It’s CVE. There is a convergence of very annoying trends happening: more and more are garbage found and written using AI and with an impact which is questionable at best, the way CVE are published and classified is idiotic and platform founding vulnerability research like Google are more and more hostile to projects leaving very little time to actually work on fixes before publishing. This is le…

CVEs aren't caused by bugs?

Not always, there have been a plenty of CVEs issued for completely absurd reasons.

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

#648

Post by josephg »

WesolyKubeczek wrote: post #624
maybewhenthesun wrote: post #590

Earlier quoted context omitted.

While there's sometimes maintainer-prima-donna egos the contend with there's also this: Any patch sent in also needs to be maintained into the future, and most of the time it's the maintainers that need to do that, not the people contributing the patch. Therefore any feature-patches (as opposed to simple bugfixes) are quite often refused, even if they add useful functionality, because the maintainers conclude they wi…

Not any patch. Sometimes there are patches that are not explicitly fixing defects, but for example they surface a boolean setting that some upstream library started to expose. That setting is exactly like a dozen other settings already there. It's made using the same coding style and has all requisite things other settings have. Will you be still making a fuss over it?

Maybe, it depends!

Maybe the developer intends to some day change the internal implementation, such that that particular boolean flag wouldn't make sense any more. Or they're considering taking out the option entirely, and thus simplifying the codebase by making it so it only works one way.

Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work? I'm not your employee. Your product doesn't put a roof over my head.

I don't want a job where I do free work, for a bunch of companies who all make money off my work. That's a bad deal. Its a bad deal even if my code gets better as a result. I have 150 projects on github. I don't want to be punished if any of those projects become popular.

We can't go around punishing projects like ffmpeg or ruby on rails for the crime of being useful.

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

#649

Post by surajrmal »

zxspectrum1982 wrote: post #75
phkahler wrote: post #54

From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…

Google is not paying anyone to find bugs. They are running AIs indiscriminately.

A human at Google investigates all of the bugs fuzzers and AI find manually and manually writes bug reports for upstream with more analysis. They are certainly paid to do that. They are also paid to develop tooling to find bugs.

I'm not sure what you think you mean when you say "running AIs indiscriminately". It's quite expensive to run AI this way, so it needs to be done with very careful consideration.

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

#650

Post by poulpy123 »

phkahler wrote: post #54

From TFA this was telling: Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and liste…

Nothing says solid industry better than having 3 majors product lines from a trillion dollar company depending of unpaid volunteer labor.
Post reply on HN