←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 #
1. rcxdude ◴[] No.45895822[source]
It's a heck of a lot better than being unaware of it.

(To put this in context: I assume that on average a published security vulnerability is known about to at least some malicious actors before it's published. If it's published, it's me finding out about it, not the bad actors suddenly getting a new tool)

replies(1): >>45897427 #
2. Brian_K_White ◴[] No.45897427[source]
it's only better if you can act on it equal to the bad guys. If the bad guys get to act on it before you, or before some other good guys do on your behalf, then no it's not better

remember we're not talking about keeping a bug secret, we're talking about using a power tool to generate a fire hose of bugs and only doing that, not fixing them