> Needless to say, OpenSSL is looking for contributors. Beyond contributing patches, interested developers can test the pre-releases, report bugs, and help to close bugs. The presenters concluded by saying that they would like users to get in touch, especially those who are distributing OpenSSL further downstream.<p>... and just a few days later they closed ~ 150 bugs, some with patches attached, "because they were too old":<p><a href="https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/" rel="nofollow">https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/</a><p><a href="https://mta.openssl.org/pipermail/openssl-dev/2016-October/008638.html" rel="nofollow">https://mta.openssl.org/pipermail/openssl-dev/2016-October/0...</a>
Whenever there's an article about OpenSSL, I get on my soapbox to talk about how shitty it is. The design is terrible, both internally and in the public API. Building it is a PITA. It is almost completely unaware of this thing called multithreading. It still is hard-coded to be able to read certificates only via disk files with fopen, despite having a screwy BIO system which is a half baked attempt at sometimes abstracting IO.<p>If it was anything other than a security library, it would have died long ago.
I recently experienced a bug with OpenSSL 1.1 and the team was pretty reactive!
I'm using OpenSSL 1.1 because it's the only DTLS implementation featuring all the extensions (OCSP stappling) and ciphersuites (AES-CCM-8) I need.
Interesting, I had no idea the changes that were happening to OpenSSL. It's sad that it took Heartbleed to kick it in the butt, but it's heartening that they appear to be heading in a better direction now.<p>I'm also curious how LibreSSL is doing—I haven't heard much about it lately. Did it fizzle, or is it still making good progress?
How come the biggest names in IT don't work towards creating a modern, better security library?<p>It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.
For me, Heartbleed was much much more than:
->At its core, Heartbleed was a simple bug, a missing buffer-length check<p>It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue.<p>We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch.<p>Imho it will take a lot more than a couple of years and a team change to reinspire faith in that brand of security. If we should at all.
> The code was hard to maintain and hard to contribute to, especially for developers in the US due to crypto export issues.<p>That's not really true: per <a href="https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration#One" rel="nofollow">https://www.bis.doc.gov/index.php/policy-guidance/encryption...</a>, publicly available software (which includes free software) just requires a notification under exception TSU. All you have to do, per <a href="https://www.law.cornell.edu/cfr/text/15/740.13" rel="nofollow">https://www.law.cornell.edu/cfr/text/15/740.13</a>, is send an email to crypt@bis.doc.gov and to enc@nsa.gov with the location of the source code. As long as you don't change the location, you never have to worry about it again.<p>The regulation even notes that simply providing source code on a public website does not constitute export to a prohibited country.<p>It's really not a big deal.<p>(Note: I am not a lawyer; this does not constitute legal advice)
The original NaCl had assembly implementations, I believe generated with a Perl script (not unlike OpenSSL's asm generator), and looking around libsodium I cannot see assembly implementations of the loops. Does anyone know why that is? I believe the Linux kernel implementation of ChaCha20 carries asm versions.
>A recently added tool will modify the code to invert the sense of the conditions in if statements to see whether the test suite catches the resulting bug; if it doesn't, there is a coverage gap in the test suite.<p>Does anyone have any info on this tool? I'm intrigued.