←back to thread

FFmpeg to Google: Fund us or stop sending bugs

(thenewstack.io)
1125 points CrankyBear | 10 comments | 11 Nov 25 18:32 UTC | HN request time: 0.001s | source | bottom
Show context
vsgherzi ◴[11 Nov 25 20:24 UTC] No.45892348[source]▶
I understand ffmpeg being angry at the workload but this is how it is with large open source projects. Ffmpeg has no obligation to fix any of this. Open source is a gift and is provided as is. If Google demanded a fix I could see this being an issue. As it is right now it just seems like a bad look. If they wanted compensation then they should change the model, there's nothing wrong with that. Google found a bug, they reported it. If it's a valid bug then it's a valid bug end of story. Software owes it to its users to be secure, but again it's up to the maintainers if they also believe that. Maybe this pushes Google to make an alternative, which I'd be excited for.
replies(4): >>45892463 #>>45892522 #>>45892581 #>>45895390 #
1. themafia ◴[11 Nov 25 20:40 UTC] No.45892522[source]▶
> Google found a bug

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.

replies(3): >>45892654 #>>45892702 #>>45895021 #
2. jeroenhd ◴[11 Nov 25 20:51 UTC] No.45892654[source]▶
> That does not impact their business or their operations in any way whatsoever.

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.

replies(1): >>45892880 #
3. shevy-java ◴[11 Nov 25 20:55 UTC] No.45892702[source]▶
> 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.

replies(1): >>45892914 #
4. themafia ◴[11 Nov 25 21:08 UTC] No.45892880[source]▶
And they're processing old LucasArts codec videos with it? Which is the specific bug report in question.
replies(2): >>45896141 #>>45897582 #
5. themafia ◴[11 Nov 25 21:11 UTC] No.45892914[source]▶
> Google also does not owe the ffmpeg devs anything either.

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.

replies(2): >>45893996 #>>45896496 #
6. rat9988 ◴[11 Nov 25 22:51 UTC] No.45893996{3}[source]▶
I for one welcome it. I want to know if there are some vulnerabilities in the software I use.
7. vsgherzi ◴[12 Nov 25 00:47 UTC] No.45895021[source]▶
It doesn’t matter if it affects their business or not. They found an issue and they reported it. Ffmpeg could request that they report it privately perhaps. Google has a moral duty to report the bug.

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

8. inkysigma ◴[12 Nov 25 03:37 UTC] No.45896141{3}[source]▶
It's unlikely the specific codec that is the issue but the bug report suggests that the code path could be hit by a maliciously crafted payload since ffmpeg does file fuzzing. They almost certainly have ffmpeg stuff that touches user submitted videos.
9. milkey_mouse ◴[12 Nov 25 04:55 UTC] No.45896496{3}[source]▶
> Then they can stop reporting bugs with their asinine one size fits all "policy." It's unwelcome and unnecessary.

Right, they should just post the 0days on their blog.

10. jeroenhd ◴[12 Nov 25 08:13 UTC] No.45897582{3}[source]▶
They're probably not manually selecting which codecs and codec parameters to accept and sticking to the default ones instead.

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