4 ms·

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

• nonrandomstring 3y ago
  > 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".
  • xyzzy_plugh 3y ago
    "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.
    • nonrandomstring 3y ago
      > "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 https://cybershow.uk/episodes.php?id=2 [1] www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
• prmoustache 3y ago
  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.