Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

111–120 of 913 posts

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

#111
post #21

Its a special kind of irony to post AI slop complaining about someone's ai slop that isn't actually ai slop just devs whining about being expected to maintain their code instead of being able to extort the messengers to do the work for them.

If they're not being paid, they're under no obligation to "maintain their code". If you don't like it, don't use ffmpeg.

It's not "whining" to refuse to do unpaid labor for the benefit of someone else - especially when the someone else is as well-resourced as Google.

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

#112
post #80

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.

[deleted]

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

#114
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…

I think the discussion on what standard practice should be does need to be had. This seems to be throwing blame at people following the current standard.

If the obscure coded is not included by default or cannot be triggered by any means other than being explicitly asked for, then it would be reasonable to tag it Won't Fix. If it can be triggered by other means, such as auto file type detection on a renamed file, then it doesn't matter how obscure the feature is, the exploit would affect all.

What is the alternative to a time limited embargo. I don't particularly like the idea of groups of people having exploits that they have known about for ages that haven't been publicly disclosed. That is the kind of information that finds itself in the wrong hands.

Of course companies should financially support the developers of the software they depend upon. Many do this for OSS in the form of having a paid employee that works on the project.

Specifically, FFMPEG seems to have a problem that much of their limitation of resources comes from them alienating contributors. This isn't isolated to just this bug report.

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

#115

Earlier quoted context omitted.

Easy: ffmpeg discontinues or relicenses some ffmpeg functionality that AWS depends on for those product alines and AWS is screwed. I've seen that happen in other open source projects.

But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.

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?

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

#116

Earlier quoted context omitted.

Easy: ffmpeg discontinues or relicenses some ffmpeg functionality that AWS depends on for those product alines and AWS is screwed. I've seen that happen in other open source projects.

But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.

It still takes expensive humans to do this so they are incentivized to use the free labor.

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

#117

Just mark CVEs as bugs and get to them when you can. In this case, if Google doesn't like it, then so be it. It'll get fixed eventually. Don't like how long it takes? Pay someone to contribute back. Until then, hurry up and wait.

That’s how you get your open source software removed from distributions and eventually forked.

Forked by people who are quicker at fixing security vulnerabilities than the original maintainers?

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

#118
post #76

Earlier quoted context omitted.

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.

This is a fantastic argument for the universe where Google does not disclose vulnerability until the maintainers had had reasonable time to fix it. In this world the user is left vulnerable because attackers can use published vulnerabilities that the maintainers are to overwhelmed to fix

This program discloses security issues to the projects and only discloses them after they have had a "reasonable" chance to fix it though, and projects can request extensions before disclosure if projects plan to fix it but need more time.

Google runs this security program even on libraries they do not use at all, where it's not a demand, it's just whitehat security auditing. I don't see the meaningful difference between Google doing it and some guy with a blog doing it here.

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

#119
post #81

I don't understand the rational for announcing that a vulnerability in project X was discovered before the patch is released. I read the project zero blogspot announcement but it doesn't make much sense to me. Google claims this is help downsteam users but that feels like a largely non-issue to me. If you announce a vulnerability (unspecified) is found in a project before the patch is released doesn't that just incen…

Maybe for a small project? I think the difference here is rather minimal. Everybody "knows" code often has security bugs so this announcement wouldn't technically be new information. For a large project such as ffmpeg, I doubt there is a lack of effort in finding exploits in ffmpeg given how widely it is used.

I don't see why actors would suddenly reallocate large amounts of effort especially since a patch is now known to be coming for the issue that was found and thus the usefulness of the bug (even if found) is rather limited.

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

#120

Earlier quoted context omitted.

But if it gets relicensed, they would still be able to use the current version. Amazon definitely would be able to fund an independent fork.

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?

If they can fund a fork, they can continue business as usual until the need arises
Post reply on HN