Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

361–370 of 913 posts

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

#361

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…

I've been a proponent of upstreaming fixes for open source software. Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do. Unfortunately, in my experience, there's often a lot of barriers within comp…

I've literally had my employer's attorneys tell me I can't upstream patches because it would put my employer's name on the project, and they don't want the liability.

No, it didn't help giving them copies of licenses that have the usual liability clauses.

It seems a lot of corporate lawyers fundamentally misunderstand open source.

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

#362
post #24

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. To me its okay to “demand” from a for profit company (eg google) to fix an issue fast. Because they have ressources. But to “demand” that an oss project fix something with a certain (possibly tight) timeframe.. well I’…

On the other hand as an ffmpeg user do you care? Are you okay not being told a tool you're using has a vulnerability in it because the devs don't have time to fix it? I mean someone could already be using the vulnerability regardless of what Google does.

I have about 100x as much sympathy for an open source project getting time to fix a security bug than I do a multibillion dollar company with nearly infinite resources essentially blackmailing a small team of developers like this. They could -easily- pay a dev to fix the bug and send the fix to ffmpeg.

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

#363
post #352
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.

If you need this kind of security, build ffmpeg with only decoders you find acceptable

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

#364

Earlier quoted context omitted.

Sounds like it would be a lot of churn for nothing; if they can fund a fork, then they could fund the original project, no?

They COULD, but history has shown they would rather start and maintain their own fork. It might not make sense morally, but it makes total sense from a business perspective… if they are going to pay for the development, they are going to want to maintain control.

Do they want control or do they really want something that works that they don't have to worry about?

The only reason for needing control would be if it was part of their secret sauce and at that point they can fork it and fuck off.

These companies should be heavily shamed for leaching off the goodwill of the OSS community.

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

#365
post #341

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…

I think it’s exceedingly reasonable for a maintainer to dispute the severity of a vulnerability, and to ultimately decide the severity.

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

#366
post #17

This is dumb. Obscurity doesn’t create security. It’s unfortunate if ffmpeg doesn’t have the money to fix reported bugs but that doesn’t mean they should be ignorant of them. I don’t see any entitlement out of Google either - I expected this article would have a GH issue thread with a whiny YouTube engineer yelling at maintainers.

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 indefinitely without even disclosing its existence. Certainly, ffmpeg developers do not owe security to their users, but security researchers consider that they have a duty to disclose them, even if they go unfixed (and I think most people would prefer to know an unfixed vulnerability exists than to get hit by a 0-day attack). There's gotta be a point where you disclose a vulnerability, the deadline can never be indefinite, otherwise you're just very likely allowing 0-day attacks to occur (in fact, I would think that if this whole thing never happened and we instead got headlines in a year saying "GOOGLE SAT ON CRITICAL VULNERABILITY INVOLVED IN MASSIVE HACK" people would consider what Google did to be far worse).

To be clear, I do in fact think it would be very much best if Google were to use a few millionths of a percent of their revenue to fund ffmpeg, or at least make patches for vulnerabilities. But regardless of how much you criticize the lack of patches accompanying vulnerability reports, I would find it much worse if Google were to instead not report or disclose the vulnerability at all, even if they did so at the request of developers saying they lacked resources to fix vulnerabilities.

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

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

Nah, ffmpeg volunteers dont owe you or Google anything. They are giving you free access to their open project.

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

#368

Earlier quoted context omitted.

> era-defining software for free chill, nobody knows what ffmpeg is

Is this sarcasm? While it may be true that my mother does not know what ffmpeg is I'm almost positive she interacts with stuff that uses it literally every single day.

...every media post on IG/FB/X/YT/news sites/AI.

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

#369

Earlier quoted context omitted.

Is it? I’ve gotten nothing but headaches from these automated CVE-seeking teams.

You got lower chances of getting hacked by a random file on the internet. At Project Zero level they're also not CVE seeking - it doesn't even matter at that scale, it's not an independent trying to become known.

I have yet to see one on any project I’ve been attached to that was actually exploitable under real circumstances. But the CVE hunting teams treat them all as if they were.

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

#370
post #339

Earlier quoted context omitted.

Publishing the vulnerability is a demand to fix it. It threatens to cause harm to the reputation of the maintainer if left unfixed.

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.
Post reply on HN