- Apr 20, 2017
-
-
Marek Klein authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/576)
-
Rich Salz authored
Updated after code review, and fix indenting Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
-
Rich Salz authored
The issues were introduced by commit 93d02986 . Reviewed-by:
-
Richard Levitte authored
"skip() needs to know $how_many tests are in the block" Reviewed-by:
-
Richard Levitte authored
Note that these guards are still needed around local header files that declare linkable symbols. Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3259)
-
Richard Levitte authored
Because many of our test programs use internal headers, we need to make sure they know how, exactly, to mangle the symbols. So far, we've done so by specifying it in the affected test programs, but as things change, that will develop into a goose chase. Better then to declare once and for all how symbols belonging in our libraries are meant to be treated, internally as well as publically. Reviewed-by:
-
- Apr 19, 2017
-
-
Jon Spillett authored
Reviewed-by:
-
Todd Short authored
Reviewed-by:
-
Rich Salz authored
Add callback function prototypes, fix description Reviewed-by:
Kurt Roeckx <kurt@openssl.org> Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
- Apr 18, 2017
-
-
Richard Levitte authored
The internals test programs access header files that aren't guarded by the public __DECC_INCLUDE_PROLOGUE.H and __DECC_INCLUDE_EPILOGUE.H files, and therefore have no idea what the naming convention is. Therefore, we need to specify that explicitely in the internals test programs, since they aren't built with the same naming convention as the library they belong with. Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3247)
-
Richard Levitte authored
When building object files for libraries, information whether the library would be installed or not wasn't passed down to the object file building rules. Also, make it so settings like |no_inst_lib_cflags| can be the empty string. Reviewed-by:
-
Rich Salz authored
ct_test,evp_extra_test,wpackettest,packettest Add strncmp TEST wrappers And make some style/consistency fixes to ct_test Silence travis; gcc bug? Reviewed-by:
-
Rich Salz authored
modes_internal_test, sslcorrupttest, v3nametest Reviewed-by:
-
Rich Salz authored
randtest, cipher_overhead_test, bioprintest, constant_time_test Move test_bioprint to 04 group Reviewed-by:
-
Rich Salz authored
recordlentest, srptest, ecdsatest, enginetest, pbelutest Reviewed-by:
-
Robbie Harwood authored
Reviewed-by:
-
Robbie Harwood authored
Reviewed-by:
-
Robbie Harwood authored
Reviewed-by:
-
Robbie Harwood authored
Reviewed-by:
-
Thiago Arrais authored
Reviewed-by:
Viktor Dukhovni <viktor@openssl.org> Reviewed-by:
-
- Apr 17, 2017
-
-
Andy Polyakov authored
Trouble was that integer negation wasn't producing *formally* correct result in platform-neutral sense. Formally correct thing to do is -(int64_t)u, but this triggers undefined behaviour for one value that would still be representable in ASN.1. The trigger was masked with (int64_t)(0-u), but this is formally inappropriate for values other than the problematic one. [Also reorder branches to favour most-likely paths and harmonize asn1_string_set_int64 with asn1_get_int64].] Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
Rich Salz authored
If EC support is enabled we should catch also EC_R_UNKNOWN_GROUP as an hint to an unsupported algorithm/curve (e.g. if binary EC support is disabled). Before this commit the issue arise for example if binary EC keys are added in evptests.txt, and the test is run when EC is enabled but EC2m is disabled. E.g. adding these lines to evptests.txt would reproduce the issue: ~~~ PrivateKey=KAS-ECC-CDH_K-163_C0 -----BEGIN PRIVATE KEY----- MGMCAQAwEAYHKoZIzj0CAQYFK4EEAAEETDBKAgEBBBUAZlO2B3OY+tx79eYBWBcB SMPcRSehLgMsAAQHH4sod9YCfZwa3kJE8t6hJpLvI9UFwV7ndiIccrhLNHzjg/OA Z7icPpo= -----END PRIVATE KEY----- PublicKey=KAS-ECC-CDH_K-163_C0-PUBLIC -----BEGIN PUBLIC KEY----- MEAwEAYHKoZIzj0CAQYFK4EEAAEDLAAEBx+LKHfWAn2cGt5CRPLeoSaS7yPVBcFe 53YiHHK4SzR844PzgGe4nD6a -----END PUBLIC KEY----- PublicKey=KAS-ECC-CDH_K-163_C0-Peer-PUBLIC -----BEGIN PUBLIC KEY----- MEAwEAYHKoZIzj0CAQYFK4EEAAEDLAAEBXQjbxQoxDITCUZ4Ols6q7bCfqXWB5CM JRuNoCHLrCgfEj969PrFs9u4 -----END PUBLIC KEY----- Derive=KAS-ECC-CDH_K-163_C0 PeerKey=KAS-ECC-CDH_K-163_C0-Peer-PUBLIC Ctrl=ecdh_cofactor_mode:1 SharedSecret=04325bff38f1b0c83c27f554a6c972a80f14bc23bc ~~~ Reviewed-by:
-
- Apr 16, 2017
-
-
Kurt Roeckx authored
This adds a way to use the last byte of the buffer to change the behavior of the server. The last byte is used so that the existing corpus can be reused either without changing it, or just adding a single byte, and that it can still be used by other projects. Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
-
Kurt Roeckx authored
Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
- Apr 14, 2017
-
-
Nicola Tuveri authored
When compiling without EC support the test fails abruptly reading some keys. Some keys merged in commit db04055 start with ------BEGIN EC PRIVATE KEY----- this format is not supported without EC support. This commit reformat those keys with the generic format. After this change the test simply skips the unsupported EC keys when EC is disabled, without parsing errors. Reviewed-by:
-
Nicola Tuveri authored
All tests from ecdhtest.c have been ported to evptests.txt Reviewed-by:
-
Nicola Tuveri authored
move NIST SP800-56A co-factor ECDH KATs from ecdhtest.c to evptests.txt Reviewed-by:
-
Rich Salz authored
verify_extra_test still failing :( Reviewed-by:
-
Todd Short authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
i.e. reduce amount of branches and favour likely ones. Reviewed-by:
-
Andy Polyakov authored
If $_ is not private, it can wipe caller's one, which proved to be problematic... Reviewed-by:
-
