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?
FFmpeg to Google: Fund us or stop sending bugs
81–90 of 913 posts
Re: FFmpeg to Google: Fund us or stop sending bugs
#82A 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#83Does Google seriously not have a whole team of people who help maintain ffmpeg?
Re: FFmpeg to Google: Fund us or stop sending bugs
#84Earlier 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…
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
#85Earlier 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#86Just 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#87I 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.
Re: FFmpeg to Google: Fund us or stop sending bugs
#88I’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…
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
#89From 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?
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
#90Earlier 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.