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

351–360 of 913 posts

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

#351

Post by astrange »

jsnell wrote: post #333
astrange wrote: post #314

Earlier quoted context omitted.

The problem with security reports in general is security people are rampant self-promoters. (Linus once called them something worse.) Imagine you're a humble volunteer OSS developer. If a security researcher finds a bug in your code they're going to make up a cute name for it, start a website with a logo, Google is going to give them a million dollar bounty, they're going to go to Defcon and get a prize and I assume…

Except that the only people publicizing this bug were the people running the ffmpeg Twitter account. Without them it would have been one of thousands of vulnerabilities reported with no fanfare, no logos, and no conference talks. Doesn't really fit with your narrative of security researchers as shameless glory hounds, does it?

How do they know that next week it's not going to be one of those 10 page Project Zero blog posts? (Which like all Google engineer blog posts, usually end up mostly being about how smart the person who wrote the blog post is.)

Note FFmpeg and cURL have already had maintainers quit from burnout from too much attention from security researchers.

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

#352

Post by bragr »

xethos wrote: post #341
woodruffw wrote: post #10

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

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.

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

#353

Post by astrange »

deaddodo wrote: post #330
astrange wrote: post #311

Earlier quoted context omitted.

ffmpeg cannot relicense anything because it doesn't own anything. The contributors own the license to their code.

I don’t know about ffmpeg, but plenty of OSS projects have outlined rules for who/when a project-wide/administrative decision can be made. It’s usually outlined in a CONTRIB or similar file.

Doubtful that's enough for a copyright grant. You'd need a signed CLA.

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

#354

Post by ahepp »

f33d5173 wrote: post #291
ahepp wrote: post #266

Earlier quoted context omitted.

What is the mission of Project Zero? Is it to build a vulnerability database, or is it to fix vulnerabilities? If it's to fix vulnerabilities, it seems within reason to expect a patch. If the reason Google isn't sending a patch is because they truly think the maintainers can fix it better, then that seems fair. But if Google isn't sending a patch because fixing vulns "doesn't scale" then that's some pretty weak sauce…

If you are deliberately shipping insecure software, you should stop doing that. In ffmpeg's case, that means either patching the bug, or disabling the codec. They refused to do the latter because they were proud of being able to support an obscure codec. That puts the onus on them to fix the bug in it.

I can tell you with 100% certainty that there are undiscovered vulnerabilities in the Linux kernel right now. Does that mean they should stop shipping?

I do think that contributing fuzzing and quality bug reports can be beneficial to a project, but it's just human nature that when someone says "you go ahead and do the work, I'll stand here and criticize", people get angry.

Rather than going off and digging up ten time bombs which all start counting down together, how about digging up one and defusing it? Or even just contributing a bit of funding towards the team of people working for free to defuse them?

If Google really wants to improve the software quality of the open source ecosystem, the best thing they could do is solve the funding problem. Not a lot of people set out to intentionally write insecure code. The only case that immediately comes to mind is the xz backdoor attempt, which again had a root cause of too few maintainers. I think figuring out a way to get constructive resources to these projects would be a much more impressive way to contribute.

This is a company that takes a lot of pride in being the absolute best of the best. Maybe what they're doing can be justified in some way, but I see why maintainers are feeling bullied. Is Google really being excellent here?

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

#355

Post by Jyaif »

izacus wrote: post #297
FridgeSeal wrote: post #228

Earlier quoted context omitted.

Unfortunately, nobody not on Twitter can see anything except the first message, which just appears to be some corporate-deflection-speak. It’s a trillion dollar company. I’m sure they could find rifle through their couch cushions and find more than enough money and under-utilised devs to contribute finance or patches.

Google is one of the largest contributors to OSS in the world, so they're already throwing literal millions at OSS?

They have thousands of highly paid employees working on open source; they are spending at least 1 billion per year.

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

#356

Post by ndriscoll »

rmunn wrote: post #268
gowld wrote: post #252

Earlier quoted context omitted.

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

Have you ever used a piece of software that DID make guarantees about being safe? Every software I've ever used had a "NO WARRANTY" clause of some kind in the license. Whether an open-source license or a EULA. Every single one. Except, perhaps, for public-domain software that explicitly had no license, but even "licenses" like CC0 explicitly include "Affirmer offers the Work as-is and makes no representations or warr…

I don't know what our contract terms were for security issues, but I've certainly worked on a product where we had 5 figure penalties for any processing errors or any failures of our system to perform its actions by certain times of day. You can absolutely have these things in a contract if you pay for it, and mass market software that you pay for likely also has some implied merchantability depending on jurisdiction.

But yes things you get for free have no guarantees and there should be no expectations put in the gift giver beyond not being actively intentionally malicious.

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

#358

Post by vsgherzi »

themafia wrote: post #164
vsgherzi wrote: post #146

I understand ffmpeg being angry at the workload but this is how it is with large open source projects. Ffmpeg has no obligation to fix any of this. Open source is a gift and is provided as is. If Google demanded a fix I could see this being an issue. As it is right now it just seems like a bad look. If they wanted compensation then they should change the model, there's nothing wrong with that. Google found a bug, the…

> Google found a bug That does not impact their business or their operations in any way whatsoever. > If it's a valid bug then it's a valid bug end of story. This isn't a binary. It's why CVEs have a whole sordid scoring system to go along with them. > Software owes it to its users to be secure ffmpeg owes me nothing. I haven't paid them a dime.

It doesn’t matter if it affects their business or not. They found an issue and they reported it. Ffmpeg could request that they report it privately perhaps. Google has a moral duty to report the bug.

Software should be correct and secure. Of course this can’t always be the case but it’s what we should strive for. I think that’s baseline

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

#359

Post by vsgherzi »

otherme123 wrote: post #155
vsgherzi wrote: post #146

I understand ffmpeg being angry at the workload but this is how it is with large open source projects. Ffmpeg has no obligation to fix any of this. Open source is a gift and is provided as is. If Google demanded a fix I could see this being an issue. As it is right now it just seems like a bad look. If they wanted compensation then they should change the model, there's nothing wrong with that. Google found a bug, the…

>Ffmpeg has no obligation to fix any of this I read this as nobody wants CVEs open on their product, so you might feel forced to fix them. I find it more understandable if we talk about web frameworks: Wordpress don't want security CVEs open for months or years, or users would be upset they introduce new features while neglecting safety. I am a nobody, and whenever I found a bug I work extra to attach a fix in the sa…

Why is there an onus on Google to fix this? Bug bounty hunters aren’t required to submit a patch even when the target is open source.

Now should Google? Probably, it would be nice but no one has to. The gift from Google is the discovery of the bug.

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

#360

Post by tpmoney »

xethos wrote: post #341
woodruffw wrote: post #10

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

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…

On the other hand, if the bug doesn't get filed, it doesn't get fixed. Sure Google could spend some resources on fixing it themselves, but even if they did would we not likely see a complaint about google flooding the maintainers with PR requests for obscure 30 year old codec bugs? And isn't a PR even more of a demand on the maintainer's time because now there's actual code that needs to be reviewed, tests that need to be run and another person waiting for a response on the other end?

"Given enough eyeballs, every bug is shallow" right? Well, Google just contributed some eyeballs, and now a bug has been made shallow. So what's the actual problem here? If some retro game enthusiast had filed the same but report would that be "abusing" the maintainer's time? I would think not, but then we're saying that a bug report can be "abusive" simply by the virtue of who submits it. And I'm really not sure "don't assign employees to research bugs in your open source dependencies and if you do certainly don't submit bug reports on what you find because that's abusive" is the message we want to be sending to corporations that are using these projects.

Post reply on HN