summaryrefslogtreecommitdiff
path: root/src/regress/lib/libcrypto (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Move variable declaration to beginning of scope in order to make thistb2020-09-181-3/+4
| | | | test compile and pass on sparc64.
* make this test compile and pass on sparc64 by moving variable declarationstb2020-09-181-4/+9
| | | | to the beginning of the respective scopes (and out of for loops)
* move variable declaration up to top to make this compile and passtb2020-09-181-1/+1
| | | | on sparc64
* Use void function argument to appease gcc 4.2.1tb2020-09-181-1/+1
|
* fix "warning: value computed is not used"tb2020-09-181-2/+2
| | | | | Add a cast to tell gcc 4.2.1 that the return value is deliberately ignored. This makes the test compile and pass on sparc64.
* fix "warning: function declaration isn't a prototype"tb2020-09-181-3/+3
| | | | | Make tests compile and pass on sparc64 with gcc 4.2.1 by properly declaring "static int foo()" as "static int foo(void)".
* zap redundant linetb2020-09-181-2/+1
|
* hook symbols test to regresstb2020-09-181-1/+2
|
* Check availability of the symbols in Symbols.listtb2020-09-182-0/+182
| | | | | | | | | | | | | | This regress parses Symbols.list and pulls all public headers out of libcrypto's Makefile to generate a simple program that uses all public symbols. A number of symbols need to be declared extern since they are unavailable in public headers and a handful must be skipped since they are apparently architecture dependent. This would have caught the recent breakage due to the accidental removal of the NAME_CONSTRAINTS_check() function and points out a number of places where cleanup may happen in the future. discussed with beck
* Change the known output to be the expected output, so that webeck2020-09-141-1421/+1421
| | | | | | no longer ignore the expected failures from the legacy name constraints validation, and will have a regress failure if we regress.
* Use a fixed validation time in these tests so we neverbeck2020-09-141-2/+4
| | | | | have to re-generate these certificates and this should just keep working even if the certs get old
* Add new x509 certificate chain validator in x509_verify.cbeck2020-09-131-9/+90
| | | | | | | | | | | | | | | | | | | The new validator finds multiple validated chains to handle the modern PKI cases which may frequently have multiple paths via different intermediates to different roots. It is loosely based on golang's x509 validator This includes integration so that the new validator can be used via X509_verify_cert() as well as a new api x509_verify() which will return multiple chains (similar to go). The new validator is not enabled by default with this commit, this will be changed in a follow on commit. The new public API is not yet exposed, and will be finalized and exposed with a man page and a library minor bump later. ok tb@ inoguchi@ jsing@
* remove unused include that breaks regressbeck2020-09-121-1/+0
|
* Add x509_constraints.c - a new implementation of x509 name constraints, withbeck2020-09-112-5/+495
| | | | | | | regression tests. The use of the new name constraints is not yet activated in x509_vfy.c and will be activated in a follow on commit ok jsing@
* Fix a bug in PEM_X509_INFO_read_bio(3) that is very likely to causeschwarze2020-07-233-1/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use-after-free and double-free issues in calling programs. The bug was introduced in SSLeay-0.6.0 released on June 21, 1996 and has been present since OpenBSD 2.4. I found the bug while documenting the function. The bug could bite in two ways that looked quite different from the perspective of the calling code: * If a stack was passed in that already contained some X509_INFO objects and an error occurred, all the objects passed in would be freed, but without removing the freed pointers from the stack, so the calling code would probable continue to access the freed pointers and eventually free them a second time. * If the input BIO contained at least two valid PEM objects followed by at least one PEM object causing an error, at least one freed pointer would be put onto the stack, even though the function would return NULL rather than the stack. But the calling code would still have a pointer to the stack, so it would be likely to access the new bogus pointers sooner or later. Fix all this by remembering the size of the input stack on entry and cutting it back to exactly that size when exiting due to an error, but no further. While here, do some related cleanup: * Garbage collect the automatic variables "error" and "i" which were only used at one single place each. * Use NULL rather than 0 for pointers. I like bugfixes that make the code four lines shorter, reduce the number of variables by one, reduce the number of brace-blocks by one, reduce the number if if-statements by one, and reduce the number of else-clauses by one. Tweaks and OK tb@.
* Fix perl bugs that had me printing the wrong cert number for errorsbeck2020-07-161-8/+9
|
* The exit code from the perl matters herebeck2020-07-151-1/+3
|
* Don't leak the X509_STOREbeck2020-07-151-1/+3
|
* Add certificate validation tests generated using the tools frombeck2020-07-1510945-0/+444760
| | | | | | | | bettertls.com, and a verification suite to try each certificate in the same manner as the web based tests do using X509_verify. This includes the list of "known" failures today in our validaion code so we can move forward without moving back.
* Enter the certs regress directory.jsing2020-07-141-1/+2
|
* Add regress for X509_verify() using the new bundles.jsing2020-07-142-3/+369
| | | | | A number of these tests are known to fail due to bugs/incorrect verification implementation.
* Provide generated certificate bundles and roots for regress.jsing2020-07-1474-0/+3721
| | | | ok beck@ tb@
* Provide tools to build certificate changes for verify regress.jsing2020-07-144-0/+636
| | | | | | | | | | This provides a script that generates a variety of certificate chains and assembles them into bundles containing various permutations, which can be used to test our X.509 verification. A Go program is included to verify each of these bundles. ok beck@ tb@
* When X509_ATTRIBUTE_create() receives an invalid NID (e.g., -1), returnschwarze2020-06-042-5/+115
| | | | | | | | | | | failure rather than silently constructing a broken X509_ATTRIBUTE object that might cause NULL pointer accesses later on. This matters because X509_ATTRIBUTE_create() is used by documented API functions like PKCS7_add_attribute(3) and the NID comes straight from the user. This fixes a bug found while working on documentation. OK tb@ and "thanks" bluhm@
* go fmt whitespace nittb2020-05-141-3/+3
|
* reinstate an error check that was commented out while waiting for armtb2020-05-141-5/+4
| | | | packages to appear
* Fix two bugs in the AES-CBC-PKCS5 tests that didn't hide failing tests:tb2020-04-271-3/+3
| | | | | 1. Use the correct slice for comparing the cipher output 2. Fix logic error similar to the one in AES-GCM in the previous commit
* Fix a logic error that hid the failing ZeroLengthIv tests.tb2020-04-271-3/+3
| | | | This issue was fixed in lib/libcrypto/evp/e_aes.c r1.40.
* Import openssl-1.1.1d test data to base64test.cinoguchi2020-03-101-1/+97
| | | | ok bcook@ tb@
* Modify regress base64test.cinoguchi2020-03-101-11/+14
| | | | | | | | | | | | | | | | | | | | | | | - Don't remove multi line CR/LF from bt->out when NL mode base64_encoding_test removes CR/LF from bt->out to compare with the encoding result. This is fine with NO NL mode, but it goes wrong with NL mode if encoding result is larger than 64 and multi line, like below. "eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4\neHh4eHh4eHh4eHh4\n" - Use memcpy instead of asprintf to avoid lost '\0' at the end of data This test data loses trailing '\0' if using asprintf. "\x61\x47\x56\x73\x62\x47\x38\x3d\x0a\x00" - Print original data if decoding result comparison fails This change is not for importing test data, but I just notice. It prints bt->out if fail to memcmp bt->in with decoding result. ok bcook@ tb@
* Some of the test vectors that were added in the upstream committb2020-01-271-7/+9
| | | | | 4672ff74d68766e7785c2cac4c597effccef2c5c have a zero byte prepended. Run the secp224k1 ECDH tests and adjust this if needed.
* Add back the tests that were deleted in previous but not containedtb2020-01-261-1/+9
| | | | in OpenSSL's test suite.
* Adjust tests to match the change in EVP_chacha20().tb2020-01-262-11/+22
| | | | Test vectors taken from OpenSSL 1.1.1d (under OpenSSL's old license).
* whitespace from go fmt + update a commenttb2019-12-141-4/+4
|
* Run Wycheproof HMAC test vectors against libcrypto.tb2019-12-141-1/+96
|
* update to-do listtb2019-12-091-2/+1
|
* Run Wycheproof DSA P1363 test vectors against libcrypto.tb2019-12-091-19/+71
|
* update to-do listtb2019-12-031-2/+2
|
* Run Wycheproof ECDSA P1363 test vectors against libcrypto.tb2019-12-031-8/+8
|
* Add an EcPoint variant and pass it to the ECDH test runner.tb2019-12-031-20/+31
|
* Annotate test vector files with an enum which we can then pass to thetb2019-12-031-27/+48
| | | | run*Test programs as needed.
* Run additional 3004 ECDH and 1575 ECDSA test vectors against libcrypto.tb2019-11-281-3/+12
| | | | For now, skip 96 ECDH tests for secp224k1.
* move the HKDF tests up a bittb2019-11-281-68/+68
|
* update to-do listtb2019-11-281-2/+1
|
* go fmttb2019-11-281-10/+10
|
* no need for fallthroughtb2019-11-281-19/+7
|
* Run HKDF test vectors against libcrypto.tb2019-11-281-1/+95
|
* Run XChaCha20-Poly1305 test vectors against libcrypto.tb2019-11-281-14/+43
|
* typotb2019-11-281-2/+2
|
* Add to do list.tb2019-11-271-1/+7
|
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-24 08:27:29 +0000