Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

871–880 of 913 posts

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

#871

Earlier quoted context omitted.

I get that the ffmpeg people have limited time and resources, I get that it would be nice if Google (or literally anyone else) patched this themselves and submitted that upstream. But "everyone else down stream of us should compile out our security hole" is a terrible way to go about things. If this is so obscure of a bug that there's no real risk, then there's no need for anyone to worry that the bug has been report…

Here’s where I’m coming from: it would really suck if the outcome of all this was for ffmpeg to drop support for niche codecs. It may be the case that ffmpeg cannot reasonably support every format while maintaining the same level of security. In that case, it makes sense for distros to disable some formats by default. I still think it’s great that they’re supported by the ffmpeg project. I agree there would probably…

I agree, it would suck if ffmpeg dropped support for niche codec altogether. But that's orthogonal to whether or not the bug reports should be made public. And realistically the only way distros (or anyone) can know if they should or need to disable some formats by default is if the issues with those formats are public knowledge so people can make informed decisions. Otherwise you're just arbitrarily picking some formats to enable and some not to based on age or some other less useful criteria.

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

#872
post #398

Earlier quoted context omitted.

The bug report in question is obviously written by a human: https://issuetracker.google.com/issues/440183164?pli=1 It's of excellent quality. They've made things about as easy for the FFmpeg devs as possible without actually fixing the bug, which might entail legal complications they want to avoid. AI was only used to find the bug.

"obviously". You have 0 evidence for your comment. Big sleep is credited as reporter.

Thinking about it, "obviously written by a human" is not actually true. It's more accurate to say "no obvious signs of being written by AI".

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

#873

Earlier quoted context omitted.

The first thing you can do is actually read the article. The question is not about the security reports but Google's policy on disclosing the vulnerability after x days. It works for crazy lazy corps. But not for OSS projects.

In practice, it doesn't matter all that much whether the software project containing the vulnerability has the resources to fix it: if a vulnerability is left in the software, undisclosed to the public, the impact to the users is all the same. I, and I think most security researchers do too, believe that it would be incredibly negligent for someone who has discovered a security vulnerability to allow it to go unfixed…

> I, and I think most security researchers do too, believe that it would be incredibly negligent for someone who has discovered a security vulnerability to allow it to go unfixed indefinitely without even disclosing its existence.

Because security researchers want to move on from one thing to another. And nobody said indefinitely. Its about a path that works for OSS project.

Its also not about security through obscurity. You are LITERALLY telling the world check this vuln in this software. Oooh too bad the devs didnt fix it. Anybody in the sec biz would be following Google's security research.

Putting you in a spotlight and telling it doesn't make any difference is silly.

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

#874
post #768

Earlier quoted context omitted.

too bad UnitedHealthGroup is capital-E Evil and is literally running the "death panels" that insane right wing propaganda tried to scare us about

What a lot of people don't realize is that it's mostly employer HR departments running the "death panels". UHG and its competitors would be happy to sell insurance policies that cover absolutely everything with no questions asked: this would be easier for them to administer without the hassles of utilization management and claim edits. But customers — mainly large employers — demand that insurers (or third-party admi…

> UHG and its competitors would be happy to sell insurance policies that cover absolutely everything with no questions asked...But customers — mainly large employers — demand that insurers (or third-party administrators) impose more restrictive coverage rules in order to hold down medical costs.

UHG has been caught denying claims for things that employers already paid them to cover for their employees. You can't blame HR departments for that. You also can't blame HR for UHG upcoding/overbilling which eats into the limited resources of hospitals and the limited resource of taxpayer money ultimately resulting in fewer people able to get the healthcare they need just so that UHG can line their own pockets.

While HR departments do have their own issues, they're nowhere near the level of pure evil that UHG is.

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

#875

Earlier quoted context omitted.

They have not, neither have they indicated that they’re planning to do so.

I thought that was how the 90 day disclosure timeline worked?

After 90 days they just disclose the vulnerability. From there, developing an exploit is still a fairly complex task.

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

#876
post #773

Should Google be doing more to support ffmpeg? Yes. Should Google stop devoting resources to identifying and reporting security vulnerabilities in ffmpeg? I cannot bring myself to a mindset where my answer to this question is also "yes". It would be one thing if Google were pressuring the ffmpeg maintainers in their prioritization decisions, but as far as I can tell, Google is essentially just disclosing that this vu…

So clearly there's only one correct answer here? Which is what the ffmpeg folks are driving at

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

#877
post #695

Earlier quoted context omitted.

The XZ backdoor is not a bug but a malicious payload inserted by malicious actors. The security vulnerability would immediately been used as it was created by attackers. This bug is almost certainly too obscure to be found and exploited in the time the fix can be produced by Ffmpeg. On the other hand, this vuln being public so soon means any attacker is now free to develop their exploit before a fix is available. If…

A bug is a bug, regardless of the intent of the insertion. You have no idea if this bug was or wasn't intentionally inserted. It's of course very likely that it wasn't, but you don't and can't know that, especially given that malicious bug insertion is going to be designed to look innocent and have plausible deniability. Likewise, you don't know that the use of the XZ backdoor was imminent. For all you know the inten…

A 25 years old bug in software is not the same as a backdoor (not a bug, a full on backdoor..). The bug is so old if someone put it there intentionally, well congrats on the 25yo 0day.

Meanwhile the XZ backdoor was 100% meant to be used. I didn't say when and that doesn't matter, there is a malicious actor with the knowledge to exploit it. We can't say the same regarding the bug in a 1998 codec that was found by extensive fuzzing, and without obvious exploitation path.

Now, should it be patched? Absolutely, but should the patch be done asap at the cost of other maybe more important security patches? Maybe, maybe not. Not all bugs are security vulns, and not all security vulns are exploitable

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

#878
post #594

Earlier quoted context omitted.

> so Google is actively spending money on making open source projects better and more secure It looks like they are now starting to flood OSS with issues because "our AI tools are great", but don't want to spend a dime helping to fix those issues. xkcd 2347

According to the ffmpeg maintainer's own website (fflabs.eu) Google is spending plenty of dimes helping to fix issues in ffmpeg. Certainly they're spending enough dimes for the maintainers to proudly display Google's logo on their site as a customer of theirs.

Here's ffmpeg's site: https://www.ffmpeg.org

I fail to see a single Google logo. I also didn't know that Google sonehow had a contract with ffmpeg to be their customer.

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

#879
The problem lies in the fact that these companies are generating work for volunteers on a different time-scale and binding them to it by giving them X days before disclosing vulnerabilities. No one wants their project to have security vulnerabilities that might affect a lot of users, which creates pressure in dealing with them.

The open source model is broken in this regard, licenses need to address revenue and impose fees on these companies, which can be used as bug bounties. Game engines do this and so should projects like FFMPEG, etc. The details are complex of course, but the current status quo is abusing people's good will.

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

#880

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…

If Google can pay someone to find bugs, they can pay someone to fix them. Sounds like they'll just throw their employees to work on it rather than monetarily fund it, that way they can aura farm.

As a Googler, I wish I was as optimistic as you. There is an internal sentiment that valuable roles are being removed that aren't aligned with strategic initiatives, even roles that are widely believed to improve developer productivity. See the entire python maintainers team being laid off: https://www.reddit.com/r/AskProgramming/comments/1cem1wk/goo...

Roles fixing FFmpeg bugs would be a hard sell in this environment, imho.

Post reply on HN