- Nov 08, 2016
-
-
Andy Polyakov authored
Build failure was reported in GH#1818 if APPS environment was defined. Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1864)
-
- Nov 04, 2016
-
-
Rich Salz authored
Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1849) (cherry picked from commit 1e62cc12)
-
- Nov 02, 2016
-
-
Matt Caswell authored
Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
TLS1.0 and TLS1.1 say you SHOULD ignore unrecognised record types, but TLS 1.2 says you MUST send an unexpected message alert. We swap to the TLS 1.2 behaviour for all protocol versions to prevent issues where no progress is being made and the peer continually sends unrecognised record types, using up resources processing them. Issue reported by 郭志攀 Reviewed-by: Tim Hudson <tjh@openssl.org>
-
Matt Caswell authored
The heartbeat_test reaches into the internals of libssl and calls some internal functions. It then checks the return value to check its what it expected. However commit fa4c3745 changed the return value of these internal functions, and now the test is failing. The solution is to update the test to look for the new return value. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Richard Levitte authored
Forks will have to define their own Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1821) (cherry picked from commit 5e28b1c1)
-
- Nov 01, 2016
-
-
Benjamin Kaduk authored
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1625) (cherry picked from commit e4d94269)
-
- Oct 28, 2016
-
-
Richard Levitte authored
Without this, any linker flag the user gave when configuring are ignored. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1803)
-
Matt Caswell authored
Replace the various length checks in the extension code with a macro to simplify the logic. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
The previous commit inspired a review of all the length checks for the extension adding code. This adds more robust checks and adds checks where some were missing previously. The real solution for this is to use WPACKET which is currently in master - but that cannot be applied to release branches. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
The status request extension did not correctly check its length, meaning that writing the extension could go 2 bytes beyond the buffer size. In practice this makes little difference because, due to logic in buffer.c the buffer is actually over allocated by approximately 5k! Issue reported by Guido Vranken. Reviewed-by: Rich Salz <rsalz@openssl.org>
-
Matt Caswell authored
Providing a spkac file with no default section causes a double free. Thanks to Brian Carpenter for reporting this issue. Reviewed-by: Kurt Roeckx <kurt@openssl.org> (cherry picked from commit 229bd124)
-
Matt Caswell authored
A zero return from BIO_read()/BIO_write() could mean that an IO operation is retryable. A zero return from SSL_read()/SSL_write() means that the connection has been closed down (either cleanly or not). Therefore we should not propagate a zero return value from BIO_read()/BIO_write() back up the stack to SSL_read()/SSL_write(). This could result in a retryable failure being treated as fatal. Reviewed-by: Richard Levitte <levitte@openssl.org>
-
- Oct 26, 2016
-
-
Rich Salz authored
Reviewed-by: Tim Hudson <tjh@openssl.org> (cherry picked from commit 12a7715e)
-
- Oct 25, 2016
-
-
Dr. Matthias St. Pierre authored
A temporary buffer containing g^xy was not cleared in ecdh_compute_key() before freeing it, so the shared secret was leaked in memory. Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
- Oct 22, 2016
-
-
Rich Salz authored
Unhandled critical CRL extensions were not detected if they appeared after the handled ones. (GitHub issue 1757). Thanks to John Chuah for reporting this. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1769)
-
- Oct 20, 2016
-
-
Cristian Stoica authored
The structure has already been initialized to zero with memset. See also commit 64b25758 (remove 0 assignments) Signed-off-by: Cristian Stoica <cristian.stoica@nxp.com> CLA: trivial Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1463)
-
Richard Levitte authored
This avoids failures when configuring with --strict-warnings Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1749)
-
Richard Levitte authored
This removes some #ifndef clutter. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1644)
-
Richard Levitte authored
In apps/apps.c, one can set up an engine with setup_engine(). However, we freed the structural reference immediately, which means that for engines that don't already have a structural reference somewhere else (because it has registered at least one cipher or digest algorithm method, and therefore gets a functional reference through the ENGINE_set_default() call), we end up returning an invalid reference. Instead, the function release_engine() is added, and called at the end of the routines that call setup_engine(). Originally, the ENGINE API wasn't designed for this to happen, an engine had to register at least one algorithm method, and was especially expected to register the algorithms corresponding to the key types that could be stored and hidden in hardware. However, it turns out that some engines will not register those algorithms with the ENGINE_set_{algo}, ENGINE_set_cipher or ENGINE_set_digest functions, as they only want the methods to be used for keys, not as general crypto accelerator methods. That may cause ENGINE_set_default() to do nothing, and no functional reference is therefore made, leading to a premature deallocation of the engine and it thereby becoming unavailable when trying to fetch a key. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1644)
-
- Oct 19, 2016
-
-
Richard Levitte authored
Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1748)
-
Richard Levitte authored
Fixes RT#4699 Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1668)
-
- Oct 18, 2016
-
-
Patrick Steuer authored
crypto/evp/e_aes.c: Types of inp and out parameters of AES_xts_en/decrypt functions need to be changed from char to unsigned char to avoid build error due to -Werror=incompatible-pointer-types. crypto/aes/asm/aes-s390x.pl: Comments need to reflect the above change. Signed-off-by: Patrick Steuer <psteuer@mail.de> Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> CLA: trivial
-
Patrick Steuer authored
crypto/s390xcap.c: cryptlib.h needs to be included for OPENSSL_cpuid_setup function prototype is located there to avoid build error due to -Werror=missing-prototypes. Signed-off-by: Patrick Steuer <psteuer@mail.de> Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> CLA: trivial
-
- Oct 15, 2016
-
-
Steven Fackler authored
These are implemented as macros delegating to `EVP_DigestUpdate`, which takes a `size_t` as its third argument, not an `unsigned int`. CLA: trivial Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (cherry picked from commit 8bdce8d1)
-
Matt Caswell authored
If len == 0 in a call to ERR_error_string_n() then we can read beyond the end of the buffer. Really applications should not be calling this function with len == 0, but we shouldn't be letting it through either! Thanks to Agostino Sarubbo for reporting this issue. Agostino's blog on this issue is available here: https://blogs.gentoo.org/ago/2016/10/14/openssl-libcrypto-stack-based-buffer-overflow-in-err_error_string_n-err-c/ Reviewed-by: Richard Levitte <levitte@openssl.org> (cherry picked from commit e5c13615)
-
- Oct 14, 2016
-
-
Vitezslav Cizek authored
The SWEET32 fix moved 3DES from HIGH to MEDIUM, but omitted SSL2. CLA: trivial Reviewed-by: Kurt Roeckx <kurt@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1683)
-
- Oct 13, 2016
-
-
Rich Salz authored
Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1702) (cherry picked from commit 7954dced)
-
- Oct 11, 2016
-
-
Kurt Cancemi authored
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
-
- Sep 28, 2016
-
-
Richard Levitte authored
Before loading a key from an engine, it may need to be initialized. When done loading the key, we must de-initialize the engine. (if the engine is already initialized somehow, only the reference counter will be incremented then decremented) Reviewed-by: Stephen Henson <steve@openssl.org> (cherry picked from commit 49e476a5)
-
Rich Salz authored
This reverts commit 4badd2b3 . This fails to call ENGINE_finish; an alternate fix is coming. Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
-
David Woodhouse authored
Things like 'openssl s_client' only ever worked with keys from an engine which provided a default generic method for some key type — because it called ENGINE_set_default() and that ended up being an implicit initialisation and functional refcount. But an engine which doesn't provide generic methods doesn't get initialised, and then when you try to use it you get an error: cannot load client certificate private key file from engine 140688147056384:error:26096075:engine routines:ENGINE_load_private_key:not initialised:crypto/engine/eng_pkey.c:66: unable to load client certificate private key file cf. https://github.com/OpenSC/libp11/issues/107 (in which we discover that engine_pkcs11 *used* to provide generic methods that OpenSSL would try to use for ephemeral DH keys when negotiating ECDHE cipher suites in TLS, and that didn't work out very well.) Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1640)
-
- Sep 26, 2016
-
-
Matt Caswell authored
The NEWS file referenced the wrong CVE for 1.0.2 Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Note: this was accidentally omitted from OpenSSL 1.0.2 branch. Without this fix any attempt to use CRLs will crash. CVE-2016-7052 Thanks to Bruce Stephens and Thomas Jakobi for reporting this issue. Reviewed-by: Stephen Henson <steve@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
-
- Sep 22, 2016
-
-
Dirk Feytons authored
Add a missing ifdef. Same change is already present in master. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1100)
-
Rich Salz authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: Richard Levitte <levitte@openssl.org>
-