←back to thread

1125 points CrankyBear | 2 comments | | HN request time: 0s | 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 #
AbrahamParangi ◴[] No.45891930[source]
If google bears no role in fixing the issues it finds and nobody else is being paid to do it either, it functionally is just providing free security vulnerability research for malicious actors because almost nobody can take over or switch off of ffmpeg.
replies(6): >>45892251 #>>45893043 #>>45893172 #>>45896030 #>>45899685 #>>45900110 #
eddd-ddde ◴[] No.45892251[source]
So your claim is that buggy software is better than documented buggy software?
replies(2): >>45892307 #>>45893385 #
rsanek ◴[] No.45892307[source]
I think so, yes. Certainly it's more effort to both find and exploit a bug than to simply exploit an existing one someone else found for you.
replies(2): >>45892337 #>>45899330 #
jakeydus ◴[] No.45892337[source]
Yeah it's more effort, but I'd argue that security through obscurity is a super naive approach. I'm not on Google's side here, but so much infrastructure is "secured" by gatekeeping knowledge.
replies(2): >>45893192 #>>45895865 #
Brian_K_White ◴[] No.45893192[source]
I don't think you should try to invoke the idea of naivete when you fail to address the unhappy but perfectly simple reality that the ideal option doesn't exist, is a fantasy that isn't actually available, and among the available options, even though none are good, one is worse than another.

"obscurity isn't security" is true enough, as far as it goes, but is just not that far.

And "put the bugs that won't be fixed soon on a billboard" is worse.

The super naive approach is ignoring that and thinking that "fix the bugs" is a thing that exists.

replies(2): >>45893826 #>>45894886 #
rcxdude ◴[] No.45893826[source]
If I know it's a bug and I use ffmpeg, I can avoid it by disabling the affected codec. That's pretty valuable.
replies(2): >>45894301 #>>45900124 #
Brian_K_White ◴[] No.45894301[source]
More fantasy. Presumes the bug only exists in some part of ffmpeg that can be disabled at all, and that you don't need, and that you are even in control over your use of ffmpeg in the first place.

Sure, in maybe 1 special lucky case you might be empowered. And in 99 other cases you are subject to a bug without being in the remotest control over it since it's buried away within something you use and don't even have the option not to use the surface service or app let alone control it's subcomponents.

replies(2): >>45894767 #>>45895822 #
dotancohen ◴[] No.45894767[source]
The bug in question revolves around support for codec that has never been in wide use, and was only in obscure use over 25 years ago.
replies(1): >>45896740 #
1. Brian_K_White ◴[] No.45896740{3}[source]
There is no "the bug". The discussion is about what to do with the power of bug-finding tools.
replies(1): >>45900497 #
2. zamadatix ◴[] No.45900497[source]
"The bug" in question refers to the one found by the bug-finding tool the article claims triggered the latest episode of debate. Nobody is claiming it's the only bug, just that this triggering bug highlighted was a clear example of where there is actually such a clear cut line.

Google does contribute some patches for codecs they actually consume e.g. https://github.com/FFmpeg/FFmpeg/commit/b1febda061955c6f4bfb..., the bug in question was just an example of one the bug finding tool found that they didn't consume - which leads to this conversation.