3 ms·
> then hundreds of eyes would be upon it and awful code that > does this insanity would never enter official repos. As the example of OpenSSH clearly shows.
by rimantas 11y ago
> then hundreds of eyes would be upon it and awful code that
> does this insanity would never enter official repos.
As the example of OpenSSH clearly shows.
- wsx 11y agoWell, the insanity would rarely enter official releases. There is no comparison between the bugginess of BIOSes and OpenSSH.
- zanny 11y agoOpenSSH would not fit my definition of a popular project, which is exactly why it has become a security disaster. Though another contributing problem is that C as a language is awful for writing secure or trustworthy code in in the first place, which is the primary cause of most of OpenSSH's problems. There are degrees of return on code visibility, though. Even a dozen competent developers could miss arcane buffer overflows or bad page execution issues in a large patch because the language is awful and lets you do crazy shit. That is one aspect of development quality that doesn't go away when you move from closed to open source. But the best practices - consistent code style, documentation, reasonable variable names, reasonable line lengths, and the need to defend your contributions are all products of open collaborative development processes. I'd argue in many ways that the open nature of OpenSSH is why we have only had three (four?) major security vulnerabilities out of it in the last five years. Its a sixteen year old ANSI C codebase, of course its a security nightmare, but it is a lot less dangerous than it could have been - imagine having heartbleed on a proprietary TLS implementation where developers could not immediately fix it or easily deploy the fix.