That does not impact their business or their operations in any way whatsoever.
> If it's a valid bug then it's a valid bug end of story.
This isn't a binary. It's why CVEs have a whole sordid scoring system to go along with them.
> Software owes it to its users to be secure
ffmpeg owes me nothing. I haven't paid them a dime.
That is true. At the same time Google also does not owe the ffmpeg devs anything either. It applies both ways. The whole "pay us or we won't fix this" makes no sense.
Then they can stop reporting bugs with their assinine one size fits all "policy." It's unwelcome and unnecessary.
> It applies both ways.
The difference is I do not presume things upon the ffmpeg developers. I just use their software.
> The whole "pay us or we won't fix this" makes no sense.
Pay us or stop reporting obscure bugs in unused codecs found using "AI" scanning, or at least, if you do, then change your disclosure policy for those "bugs." That's the actual argument and is far more reasonable.
Right, they should just post the 0days on their blog.
Software should be correct and secure. Of course this can’t always be the case but it’s what we should strive for. I think that’s baseline
I don't know what tools and backends they use exactly, but working purely by statistics, I'm sure some place in Google's massive cloud compute empire is relying on ffmpeg to process data from the internet.
Plus, this bug was reported by AI, so it was as much a proof of concept/experiment/demonstration of their AI security scanner as it was an attempt to help secure ffmpeg