←back to thread

1125 points CrankyBear | 2 comments | | HN request time: 0.012s | source
Show context
woodruffw ◴[] No.45891521[source]
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 perfectly fine (it’s okay for projects to decide that security isn’t a priority!), but you can’t have it both ways.
replies(13): >>45891613 #>>45891749 #>>45891930 #>>45892032 #>>45892263 #>>45892941 #>>45892989 #>>45894805 #>>45896179 #>>45897077 #>>45897316 #>>45898926 #>>45900786 #
Msurrow ◴[] No.45891613[source]
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’m sure you better than me, that that’s not who volunteering works

replies(5): >>45891699 #>>45891755 #>>45891844 #>>45893088 #>>45898343 #
vadansky ◴[] No.45891699[source]
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.
replies(9): >>45891756 #>>45891762 #>>45891975 #>>45892022 #>>45892359 #>>45892632 #>>45893251 #>>45895054 #>>45900572 #
cogman10 ◴[] No.45891762[source]
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 does matter to the likes of google assuming they are using ffmpeg for their backend processing. It doesn't matter at all for just about anyone else.

You might as well tell me that `tar` has a CVE. That's great, but I don't generally go around tarring or untarring files I don't trust.

replies(4): >>45891799 #>>45891846 #>>45891931 #>>45892019 #
omnicognate ◴[] No.45891799{4}[source]
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.
replies(2): >>45891853 #>>45892520 #
cogman10 ◴[] No.45891853{5}[source]
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.

replies(2): >>45891970 #>>45902532 #
1. conradev ◴[] No.45891970{6}[source]
Firefox has moved some parsers to Rust: https://github.com/mozilla/mp4parse-rust
replies(1): >>45892360 #
2. rebelwebmaster ◴[] No.45892360[source]
Firefox also does a lot of media decoding in a separate process.