+ Changes between 0.9.8l and 0.9.8m [xx XXX xxxx]
+
+ *) Fix X509_STORE locking: Every 'objs' access requires a lock (to
+ accommodate for stack sorting, always a write lock!).
+ [Bodo Moeller]
+
+ *) On some versions of WIN32 Heap32Next is very slow. This can cause
+ excessive delays in the RAND_poll(): over a minute. As a workaround
+ include a time check in the inner Heap32Next loop too.
+ [Steve Henson]
+
+ *) The code that handled flushing of data in SSL/TLS originally used the
+ BIO_CTRL_INFO ctrl to see if any data was pending first. This caused
+ the problem outlined in PR#1949. The fix suggested there however can
+ trigger problems with buggy BIO_CTRL_WPENDING (e.g. some versions
+ of Apache). So instead simplify the code to flush unconditionally.
+ This should be fine since flushing with no data to flush is a no op.
+ [Steve Henson]
+
+ *) Handle TLS versions 2.0 and later properly and correctly use the
+ highest version of TLS/SSL supported. Although TLS >= 2.0 is some way
+ off ancient servers have a habit of sticking around for a while...
+ [Steve Henson]
+
+ *) Modify compression code so it frees up structures without using the
+ ex_data callbacks. This works around a problem where some applications
+ call CRYPTO_cleanup_all_ex_data() before application exit (e.g. when
+ restarting) then use compression (e.g. SSL with compression) later.
+ This results in significant per-connection memory leaks and
+ has caused some security issues including CVE-2008-1678 and
+ CVE-2009-4355.
+ [Steve Henson]
+
+ *) Constify crypto/cast (i.e., <openssl/cast.h>): a CAST_KEY doesn't
+ change when encrypting or decrypting.
+ [Bodo Moeller]
+
+ *) Add option SSL_OP_LEGACY_SERVER_CONNECT which will allow clients to
+ connect and renegotiate with servers which do not support RI.
+ Until RI is more widely deployed this option is enabled by default.
+ [Steve Henson]
+
+ *) Add "missing" ssl ctrls to clear options and mode.
+ [Steve Henson]
+
+ *) If client attempts to renegotiate and doesn't support RI respond with
+ a no_renegotiation alert as required by RFC5746. Some renegotiating
+ TLS clients will continue a connection gracefully when they receive
+ the alert. Unfortunately OpenSSL mishandled this alert and would hang
+ waiting for a server hello which it will never receive. Now we treat a
+ received no_renegotiation alert as a fatal error. This is because
+ applications requesting a renegotiation might well expect it to succeed
+ and would have no code in place to handle the server denying it so the
+ only safe thing to do is to terminate the connection.
+ [Steve Henson]