* Is anyone up to auditing the C code? To support my earlier concern
("http://lists.racket-lang.org/dev/archive/2014-February/013935.html";),
you've probably heard in the last few days about a C oops bug in OpenSSL
that has compromised the private keys of 2/3 of the Internet for over a
year now. I think we are going to keep seeing exploits like this in
SSL/TLS/etc. implementations, because some of the protocols are hairy,
and the implementations don't seem to be perfect like they we need them
to be.
* Are all the new (to Racket) OpenSSL code paths enabled by this change
disabled *entirely* by default, or are there some new-to-Racket code
paths that can be negotiated by the other party with the default Racket
use of OpenSSL? The reason I ask is that I believe that the fewer
unnecessary OpenSSL code paths available, the fewer OpenSSL
vulnerabilities available.
(BTW, I'm not harshing on OpenSSL entirely. OpenSSL been indispensible
for some of my work, dealing with myriad oddball security protocols that
no one wants to take the huge development cost hit of coding and
validating from scratch. But I don't have a high level of confidence in
the code.)
Neil V.
Edward Lee wrote at 04/09/2014 04:20 PM:
I previously submitted this patch in late January; I've not received any
progress updates with regards to this patch recently - did this patch
get lost between then and now?
This patch adds Perfect Forward Secrecy to Racket's OpenSSL bindings.
This patch has been tested on Ubuntu 12.04 (and appears to work
correctly in a production environment).
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
