openssl/util, branch OpenSSL_1_0_2j

mk1mf.pl: check for no-tls1 here as well

2016-09-22T08:16:08Z

Reviewed-by: Matt Caswell

mk1mf: dtlstest needs ssltestlib, include it with a hack

2016-08-22T22:09:40Z

We don't really have a mechanism to include other object files into a given test program. For now, a simple hack in mk1mf.pl will do. RT#4653 Reviewed-by: Rich Salz

Fix util/mkerr.pl

2016-05-18T20:32:13Z

- Adjust mkerr.pl to produce the line length we used for source reformating. - Have mkerr.pl keep track of preprocessor directive indentation Among others, do not spuriously throw away a #endif at the end of header files. - Make sure mkerr.pl specifies any header inclusion correctly Reviewed-by: Rich Salz

Fix SSL compression symbol exporting

2016-05-17T08:23:36Z

Some compression related functions in libssl have dummy versions to be used when compiled with no-comp. However those dummy functions were not being exported on Windows so they are unusable when dynamically linked. Reviewed-by: Richard Levitte

Fix the no-comp option for Windows

2016-03-18T12:13:11Z

no-comp on Windows was not actually suppressing compilation of the code, although it was suppressing its use. Reviewed-by: Richard Levitte

Add no-ssl2-method

2016-03-14T20:13:59Z

Reviewed-by: Viktor Dukhovni MR: #2341

Touch the correct variables for the system; shlib_wrap.sh on Solaris

2016-03-09T11:21:01Z

If there is cause to think LD_LIBRARY_PATH_32 and LD_PRELOAD_32 are appropriate variables to touch, do so. Otherwise, touch the usual LD_LIBRARY_PATH and LD_PRELOAD. This covers for older installations that don't have a mix of 32-bit and 64-bit libs. Reviewed-by: Andy Polyakov (cherry picked from commit a772e9d01a81dae132cb03107292b3ecc725e5af)

Recognise 32-bit Solaris in util/shlib_wrap.sh

2016-03-09T11:20:53Z

Submitted by Erik Forsberg Reviewed-by: Andy Polyakov (cherry picked from commit 86e75432835ec3ef7700a7103f9847e3c3d4350d)

Ensure mk1mf.pl is aware of no-weak-ssl-ciphers option

2016-03-01T12:41:49Z

Update mk1mf.pl to properly handle no-weak-ssl-ciphers Reviewed-by: Richard Levitte

CVE-2016-0798: avoid memory leak in SRP

2016-02-24T17:39:13Z

The SRP user database lookup method SRP_VBASE_get_by_user had confusing memory management semantics; the returned pointer was sometimes newly allocated, and sometimes owned by the callee. The calling code has no way of distinguishing these two cases. Specifically, SRP servers that configure a secret seed to hide valid login information are vulnerable to a memory leak: an attacker connecting with an invalid username can cause a memory leak of around 300 bytes per connection. Servers that do not configure SRP, or configure SRP but do not configure a seed are not vulnerable. In Apache, the seed directive is known as SSLSRPUnknownUserSeed. To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user is now disabled even if the user has configured a seed. Applications are advised to migrate to SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong guarantees about the indistinguishability of valid and invalid logins. In particular, computations are currently not carried out in constant time. Reviewed-by: Rich Salz