- May 15, 2017
-
-
Tomas Mraz authored
Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3442)
-
Tomas Mraz authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Pauli authored
[extended tests] Reviewed-by:
-
Pauli authored
Reviewed-by:
-
- May 12, 2017
-
-
Rich Salz authored
Suppose OPENSSL_USE_NODELETE (via Nick Reilly) Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
Rich Salz authored
Reviewed-by:
Stephen Henson <steve@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3454)
-
Todd Short authored
Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
- May 11, 2017
-
-
David Benjamin authored
The assembler already knows the actual path to the generated file and, in other perlasm architectures, is left to manage debug symbols itself. Notably, in OpenSSL 1.1.x's new build system, which allows a separate build directory, converting .pl to .s as the scripts currently do result in the wrong paths. This also avoids inconsistencies from some of the files using $0 and some passing in the filename. Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3431)
-
Rich Salz authored
Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
Todd Short authored
Issue 1: sh.bittable_size is a size_t but i is and int, which can result in freelist == -1 if sh.bittable_size exceeds an int. This seems to result in an OPENSSL_assert due to invalid allocation size, so maybe that is "ok." Worse, if sh.bittable_size is exactly 1<<31, then this becomes an infinite loop (because 1<<31 is a negative int, so it can be shifted right forever and sticks at -1). Issue 2: CRYPTO_secure_malloc_init() sets secure_mem_initialized=1 even when sh_init() returns 0. If sh_init() fails, we end up with secure_mem_initialized=1 but sh.minsize=0. If you then call secure_malloc(), which then calls, sh_malloc(), this then enters an infite loop since 0 << anything will never be larger than size. Issue 3: That same sh_malloc loop will loop forever for a size greater than size_t/2 because i will proceed (assuming sh.minsize=16): i=16, 32, 64, ..., size_t/8, size_t/4, size_t/2, 0, 0, 0, 0, .... This sequence will never be larger than "size". Reviewed-by:
-
Richard Levitte authored
BIO_socket_ioctl is only implemented on VMS for VMS version 7.0 and up, but since we only support version 7.1 and up, there's no need to check the VMS version. Reviewed-by:
-
Richard Levitte authored
Not exactly everywhere, but in those source files where stdint.h is included conditionally, or where it will be eventually Reviewed-by:
-
Richard Levitte authored
In some cases, testutil outputs subtests like this: 1..6 # Subtest: progname The standard set by Test::More (because there really is no actual standard yet) gives this display: # Subtest: progname 1..6 Until the standard is actually agreed upon, let's do it like Test::More. Reviewed-by: -
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Bernd Edlinger authored
- Mostly missing fall thru comments - And uninitialized value used in sslapitest.c Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Rich Salz authored
Add file/line# to test error message. Also remove expected/got fields since TEST structure prints them. Reviewed-by:
-
Rich Salz authored
Report test detail error. Reviewed-by:
-
Rich Salz authored
Also, allow multiple files on commandline (for future splitup of evptests.txt) Reviewed-by:
-
Tomas Mraz authored
Allow conversion of existing requests to certificates again. Fixes the issue #3396 Reviewed-by:
-
Pauli authored
The second BN_is_zero test can never be true. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3436)
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Only applies if we're not doing psk. Reviewed-by:
-
Matt Caswell authored
We abort if we read a message like this. Reviewed-by:
-
Matt Caswell authored
We should be validating that. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Previously we sent a decode_error alert. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Make sure we are using the correct alert codes as per the spec. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Dr. Stephen Henson authored
Reviewed-by:
-
