I remember so many people in the open source world angry or annoyed with the OpenBSD team for forking LibreSSL. The fact is it's more than a year later, several more high-risk vulnerabilities discovered, and OpenSSL has yet to make any noticable changes. Meanwhile those same vulnerabilities were fixed in LibreSSL due to code cleanup and removal.[1]<p>No matter how you feel about the forking or the openbsd team, there is something to be learned here. There are times when forking, deleting old code, and major clean-ups can be very useful strategies. Sunk cost bias can be an enemy of progress.<p>[1] - <a href="https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerabilities" rel="nofollow">https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...</a>
Not to miss:<p>Less code <a href="http://www.openbsd.org/papers/libtls-fsec-2015/mgp00004.html" rel="nofollow">http://www.openbsd.org/papers/libtls-fsec-2015/mgp00004.html</a><p>What's wrong with the OpenSSL API <a href="http://www.openbsd.org/papers/libtls-fsec-2015/mgp00007.html" rel="nofollow">http://www.openbsd.org/papers/libtls-fsec-2015/mgp00007.html</a><p>TLS small set of functions <a href="http://www.openbsd.org/papers/libtls-fsec-2015/mgp00009.html" rel="nofollow">http://www.openbsd.org/papers/libtls-fsec-2015/mgp00009.html</a><p>read() and write() semantics <a href="http://www.openbsd.org/papers/libtls-fsec-2015/mgp00011.html" rel="nofollow">http://www.openbsd.org/papers/libtls-fsec-2015/mgp00011.html</a><p>No need for handling errno EAGAIN/EINTR yay! <a href="http://www.openbsd.org/papers/libtls-fsec-2015/mgp00016.html" rel="nofollow">http://www.openbsd.org/papers/libtls-fsec-2015/mgp00016.html</a><p>There's more stuff like event/poll, but I don't want to link more. The presentation is very interesting.
I'm just curious and,yes, it's a bit off-topic AND forgetting the relevant dates, etc. that are at play here: isn't developing an SSL/TLS library the sort of thing that Rust should excel at? I see all those lines of C code (and clearly other non-C code) and am thinking of all the opportunities for bugs to come up related to pointer and memory management. Would such a library be a good use of Rust from the performance and safety perspective? Seems like it's how the language is being sold.<p>Note: I'm not a C developer nor do I typically work at this level of the stack, thus my seeking opinions.
Thanks to the developers for LibreSSL and libtls. I'm using both in an application I'm working on.<p>I've been meaning to post on the mailing list, but I have some requests I guess I'll try here:<p>- For libtls, accept custom read and write callbacks. libuv has no way to poll for writable: <a href="https://github.com/libuv/libuv/issues/517" rel="nofollow">https://github.com/libuv/libuv/issues/517</a><p>- I wish they would provide (and maintain) the modern cyphersuite from here: <a href="https://wiki.mozilla.org/Security/Server_Side_TLS" rel="nofollow">https://wiki.mozilla.org/Security/Server_Side_TLS</a> ("secure", "legacy" and "high" are all lacking in various ways)<p>These are fairly minor issues and overall LibreSSL and (especially) libtls have been a huge step forward. Thanks again.
I'm interested in this but it's in lack of documentation, worse than openssl at the moment.<p>for example any demo code for me to try out the libtls?