- Nov 02, 2016
-
-
Richard Levitte authored
Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1815) (cherry picked from commit 2c4a3f93)
-
Sergey Bronnikov authored
CLA: trivial Reviewed-by:
Kurt Roeckx <kurt@openssl.org> Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1801) (cherry picked from commit fe2582a2)
-
Matt Caswell authored
This test checks that read_ahead works correctly when dealing with large records. Reviewed-by:
Richard Levitte <levitte@openssl.org> (cherry picked from commit 7856332e)
-
Matt Caswell authored
The function ssl3_read_n() takes a parameter |clearold| which, if set, causes any old data in the read buffer to be forgotten, and any unread data to be moved to the start of the buffer. This is supposed to happen when we first read the record header. However, the data move was only taking place if there was not already sufficient data in the buffer to satisfy the request. If read_ahead is set then the record header could be in the buffer already from when we read the preceding record. So with read_ahead we can get into a situation where even though |clearold| is set, the data does not get moved to the start of the read buffer when we read the record header. This means there is insufficient room in the read buffer to consume the rest of the record body, resulting in an internal error. This commit moves the |clearold| processing to earlier in ssl3_read_n() to ensure that it always takes place. Reviewed-by:
-
Richard Levitte authored
Forks will have to define their own Reviewed-by:
-
- Nov 01, 2016
-
-
Benjamin Kaduk authored
Reviewed-by:
-
- Oct 31, 2016
-
-
Richard Levitte authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1802) (cherry picked from commit f46661de)
-
Richard Levitte authored
Fixes #1781 Reviewed-by:
-
Richard Levitte authored
VC-noCE-common and VC-WIN64-common were missing this line: template => 1, Fixes GH#1809 Reviewed-by:
-
- Oct 28, 2016
-
-
Matt Caswell authored
Replace the various length checks in the extension code with a macro to simplify the logic. Reviewed-by: -
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: -
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: -
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:
-
Matt Caswell authored
A BIO_read() 0 return indicates that a failure occurred that may be retryable. An SSL_read() 0 return indicates a non-retryable failure. Check that if BIO_read() returns 0, SSL_read() returns <0. Same for SSL_write(). The asyncio test filter BIO already returns 0 on a retryable failure so we build on that. Reviewed-by:
-
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:
-
- Oct 26, 2016
-
-
Richard Levitte authored
The current version of the VMS compiler provides C99 features, strictly language wise. Unfortunately, even the most recent standard library isn't fully updated for that standard, so we need to use an earlier standard that the compiler supports. Most importantly, this affects the __STDC_VERSION__ value, which the compiler unfortunately currently defaults to 199901L. With this change we won't have to give VMS special treatment when looking for features based on that macro. Reviewed-by:
-
Rich Salz authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (cherry picked from commit 12a7715e)
-
- Oct 25, 2016
-
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
This is overdue since the addition of the unified build system Reviewed-by:
-
- Oct 24, 2016
-
-
Andy Polyakov authored
Reviewed-by:
-
- Oct 22, 2016
-
-
Richard Levitte authored
Reviewed-by:
-
- Oct 21, 2016
-
-
Richard Levitte authored
Reviewed-by:
-
Claus Assmann authored
CLA: trivial Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
- Oct 20, 2016
-
-
David Woodhouse authored
I use the word 'negotiation' advisedly. Because that's all we were doing. We negotiated it, set the TLS1_FLAGS_ENCRYPT_THEN_MAC flag in our data structure, and then utterly ignored it in both dtls_process_record() and do_dtls1_write(). Turn it off for 1.1.0; we'll fix it for 1.1.1 and by the time that's released, hopefully 1.1.0b will be ancient history. Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
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's a built in engine), 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(). Reviewed-by:
-
- Oct 19, 2016
-
-
Andrea Grandi authored
Reviewed-by:
-
Mat authored
Only set the load_crypto_strings_inited to 1 when err_load_crypto_strings_int was called. This solves the following issue: - openssl is built with no-err - load_crypto_strings_inited is set to 1 during the OPENSSL_init_crypto call - During the cleanup: OPENSSL_cleanup, err_free_strings_int is called because load_crypto_strings_inited == 1 - err_free_strings_int calls do_err_strings_init because it has never been called - Now do_err_strings_init calls OPENSSL_init_crypto - But since we are in the cleanup (stopped == 1) this results in an error: CRYPTOerr(CRYPTO_F_OPENSSL_INIT_CRYPTO, ERR_R_INIT_FAIL); - which then tries to initialize everything we are trying to clean up: ERR_get_state, ossl_init_thread_start, etc Reviewed-by:
-
FdaSilvaYY authored
Reviewed-by:
-
Andrea Grandi authored
Reviewed-by:
-
- Oct 17, 2016
-
-
Dr. Stephen Henson authored
Don't rely on embedded flag to free strings correctly: it wont be set if there is a malloc failure during initialisation. Thanks to Guido Vranken for reporting this issue. Reviewed-by:
-
choury authored
CLA: trivial Reviewed-by:
-
- 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:
-
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:
-
- Oct 14, 2016
-
-
Tomas Mraz authored
Copy the whole ALG_OP_TYPE to CMSG_DATA. Reviewed-by:
-
Xiaoyin Liu authored
I think the second "VC-WIN32" should be "VC-WIN64". Reviewed-by:
-
- Oct 13, 2016
-
-
Vitezslav Cizek authored
The number is taken from the OPENSSL_VERSION_NUMBER which is already in the hex form. CLA: trivial Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
