Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

71–80 of 913 posts

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

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

It is accurate. This is a codec that was added for archival and digital preservation purposes. It’s like adding a Unicode block for some obscure 4000 year old dead language that we have a scant half dozen examples of writing.

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

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

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

#73

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…

How could ffmpeg maintainers kill three major AWS product lines with an email?

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

#74

Earlier quoted context omitted.

AIUI, (lib)ffmpeg is used by practically everything that does anything with video, including such definitely-security-sensitive things as Chrome, which people use to play untrusted content all the time.

hmm, didn't realize chrome was using ffmpeg in the background. That definitely makes it more dangerous than I supposed. Looks like firefox does the same.

Firefox has moved some parsers to Rust: https://github.com/mozilla/mp4parse-rust

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

#75

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.

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

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

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

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

#77

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…

How could ffmpeg maintainers kill three major AWS product lines with an email?

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.

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

#78
post #42
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’…

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.

> That is standard practice.

It's standard practice for commercially-sponsored software, and it doesn't necessarily fit volunteer maintained software. You can't have the same expectations.

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

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