Live data from Hacker News

FFmpeg to Google: Fund us or stop sending bugs

thenewstack.io

81–90 of 913 posts

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

#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 incentivize bad actors to now direct their efforts at finding a vulnerability in that project?

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

#82
post #20

A bunch of people who make era-defining software for free. A labor of love. Another bunch of people who make era-defining software where they extract everything they can. From customers, transactionally. From the first bunch, pure extraction (slavery, anyone?).

Irrespective of what Google does, security research is still useful for all of us. They could adopt a more flexible policy for FOSS though.

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

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

#84

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.

Sure but how. Let's say that FFMPEG has a 10 CVE where a very easy stream can cause it to RCE. So what? We are talking about software commonly for end users deployed to encode their own media. Something that rarely comes in untrusted forms. For an exploit to happen, you need to have a situation where an attacker gets out a exploited media file which people commonly transcode via FFMPEG. Not an easy task. This sure do…

ffmpeg is also megabytes of parsing code, whereas tar is barely a parser.

It would be surprising to find memory corruption in tar in 2025, but not in ffmpeg.

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

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

If you use a trillion dollar AI to probe open source code in ways that no hacker could, you're kind of unearthing the vulnerabilities yourself if you disclose them.

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

#86

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.

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

#87

I get the idea of publicly disclosing security issues to large well funded companies that need to be incentivized to fix them. But I think open source has a good argument that in terms of risk reward tradeoff, publicly disclosing these for small resource constrained open source project probably creates a lot more risk than reward.

You are missing the tiny little fact that apparently a large portion of infosec people are of the opinion that insecure software must not exist. At any cost. No shades of gray.

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

#88

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…

> But appearance is operative: a security issue is something that I (as the maintainer) would need to fix regardless of who reports it

I think this is the heart of the issue and it boils off all of the unimportant details.

If it's a real, serious issue, you want to know about it and you want to fix it. Regardless of who reports it.

If it's a real, but unimportant issue, you probably at least want to track it, but aren't worried about disclosure. Regardless of who reports it.

If it's invalid, or AI slop, you probably just want to close/ignore it. Regardless of who reports it.

It seems entirely irrelevant who is reporting these issues. As a software project, ultimately you make the judgment call about what bugs you fix and what ones you don't.

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

#89

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?

I'd guess Prime Video heavily relies on ffmpeg, then you got Elastic Transcode and the Elemental Video Services. Probably Cloudfront also has special things for streaming that rely on ffmpeg.

The "kill it with an email" probably means that whoever said this is afraid that some usecase there wouldn't stand up to an audit by the usual patent troll mothercluckers. The patents surrounding video are so complex, old and plentiful that I'd assume full compliance is outright impossible.

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

#90
post #27
post #13

Earlier quoted context omitted.

In addition to your point, it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days. The security issue should certainly be disclosed - when its responsible to do so. Now, if Google or whoever really feels like fixing fast is so important, then they could very well contribute by submitting a patch along with their issue report. Then everybody wins.

> it seems obvious that disclosure policy for FOSS should be “when patch available” and not static X days This is very far from obvious. If google doesn't feel like prioritising a critical issue, it remains irresponsible not to warn other users of the same library.

Unless the maintainers are incompetent or uncooperative this does not feel like a good strategy. It is a good strategy on Google's side because it is easier for them to manage
Post reply on HN