Hacker News Reader

Comment by candiddevmike | Hacker News Reader

> With proprietary/closed code, the probability is zero.

People discover bugs all the time in closed source software...

I'm sure that lots of HNers including myself have encountered security vulns in different proprietary pieces of software that we encounter.

I can think of at least two or three occasions where I discovered an exploitable vuln, didn't have a contact to report it to, decided I didn't want to have the back-and-forth of some non tech company threatening me with a lawsuit, and took no further action (typically for lower severity vulns in less important services).

With open source software you can hop on GitHub and dig deeper into a vuln or other bug and actually report it somewhere.

True. What is missing is the next step - looking at the code and figuring out why the weird thing is going on. In closed source, what'd happen is a call to support, who may or may not properly file a bug, which may or may not get to the eyes of an engineer that knows what's going on, who may or may not be interested in actually fixing it... But more likely it'd end up in the huge pile of "you're just holding it wrong" tickets and nobody ever would pay attention to it, because it's impossible for one company to pay attention to millions of weird complaints, and nobody else can. It's a numbers game, and with closed source, the numbers are much less favorable, because it's economically impossible for it to be otherwise.

Which people?

Customers, though they usually aren't finding security vulnerabilities.

> Customers

Ah I see what you mean.

Problem of language then.

"Finding bugs", to me as a coder, means something different from observing the effects of bugs.

Sure, I can see incorrect behaviours in lots of proprietary software. And I can guess what might cause it. But without the source code that's not the same as "finding bugs".

"finding a bug" in source code implies there's a mistake there. A bug can be that the implementation doesn't match the spec, or that the spec changed, with respect to the user (customer).

Reporting bugs vs finding them is perhaps what you're looking for, but I'd argue finding is overloaded. It's perfectly valid to kick the tires on some software and find some bugs.

I've found thousands of bugs in closed source software before, and subsequently reported those bugs.

> "finding a bug" in source code implies there's a mistake there.

This is a good point of course. Implementation, protocol and runtime bugs are indeed invisible from the source POV. As are lower level Ken Thompson "trusting trust" [0,1] bugs in your tool chain.

Most of all though, many "bugs" are just malicious functions the coders meant to put in there.

[0] https://cybershow.uk/episodes.php?id=2

[1] www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

In this very blogpost, we are very much in a situation where users (github + the author) found the bug.

They however didn't find the cause of the bug.

And in many software, open source or proprietary, there are a lot of bugs sitting out in issues tracker for days, weeks, months or even years.

https://googleprojectzero.blogspot.com/ immediately comes to mind (though its not a good example of an anyone set of people)

Three letter agencies, and blackhats, who have the code even though it's not "open". They then use those vulnerabilities without disclosing them or fixing them, for as long as they're able.

Amen to that. Damn right proprietary code is a double danger in that regard. Officially illegal to inspect, except to a few criminals. Isn't the entirety of Microsoft's Windows code now "out there"? It has been for years, right?

Reply on news.ycombinator.com