4 ms·
> I suspect that the vast majority of people would take a 50% performance hit if it yielded a library that had only half as many major flaws as we've seen How
by fractalb 10y ago
> I suspect that the vast majority of people would take a 50% performance hit if it yielded a library that had only half as many major flaws as we've seen
How would one know whether there are any major flaws in a code base?
- kbenson 10y agoYou don't, for sure. But when half the security bugs seem to be related to memory corruption and buffer overflows, there are options. We've had languages that put more emphasis on being correct and safe than on performance, but people haven't been using them for much. C/C++ have momentum and people that know how to use them, so they are used. I'm not sure that makes them a good choice for security related work, where bugs sometimes counter the entire purpose of the library.
- e12e 10y agoOpenssl very much falls into the "so complicated / complected that there are no obvious flaws"-bin, while something like NaCl is closer to "So simple there are obviously no flaws" one. Note that there turned out to be a distressing number of obvious bugs in Openssl, and that it's doubtful that all serious bugs in a full, real-world crypto stack (especially perhaps if you demand support for x509) could ever be obvious. Ed: see also: http://www.openbsd.org/papers/bsdcan14-libressl/ http://www.openbsd.org/papers/bsdcan14-libressl/