summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Fix NULL dereference in x509_constraints_uri_host()tb2022-11-281-2/+3
| | | | | | | | | When called from v2i, hostpart in x509_constraints_uri_host() is NULL, so add a NULL check before storing the strdup result in it. From Anton Borowka ok jsing miod
* In bio.h rev. 1.50 and rev. 1.51, tb@ provided BIO_set_retry_reason(3).schwarze2022-11-271-4/+20
| | | | | Merge the documentation from the OpenSSL 1.1.1 branch, which is still under a free license, tweaked by me.
* Make header guards of internal headers consistenttb2022-11-2616-56/+55
| | | | | Not all of them, only those that didn't leak into a public header... Yes.
* bn_lcl.h wanted special treatment.tb2022-11-261-567/+0
|
* Make internal header file names consistenttb2022-11-26445-970/+1536
| | | | | | | | | | | | | | | | Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names used for internal headers. Move all these headers we inherited from OpenSSL to *_local.h, reserving the name *_internal.h for our own code. Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h. constant_time_locl.h is moved to constant_time.h since it's special. Adjust all .c files in libcrypto, libssl and regress. The diff is mechanical with the exception of tls13_quic.c, where #include <ssl_locl.h> was fixed manually. discussed with jsing, no objection bcook
* Remove BIGNUM consistency macros.jsing2022-11-2623-328/+24
| | | | | | | | | | | | Compiling with BN_DEBUG (and if you want to take it further, BN_DEBUG_RAND) supposedly adds consistency checks to the BN code. These are rarely if ever used and introduce a bunch of clutter in the code. Furthermore, there are hacks in place to undo things that the debugging code does. Remove all of this mess and instead rely on always enabled checks, more readable code and proper regress coverage to ensure correct behaviour. "Good riddance." tb@
* cms_lcl.h should not be part of SRCStb2022-11-261-2/+1
|
* In bio.h rev. 1.46/1.47 (Oct/Nov 2021), tb@ provided BIO_get_init(3).schwarze2022-11-251-5/+23
| | | | Document it.
* Units generally help...tb2022-11-251-2/+2
|
* Major overhaul.schwarze2022-11-241-210/+216
| | | | | | | | | | Remove many statements that are no longer true after tb@, in July, massively improved the algorithms used by these functions and also did some cleanup of the interface. Instead, explain many aspects that were missing. Also use more descriptive argument names, drop some redundancy, and improve ordering in various respects. Feedback and enthusiastic OK from tb@.
* Mark BN_options() and BN_prime_checks as obsolete;schwarze2022-11-241-1/+2
| | | | | it appears that all BN public symbols are now documented, except those intentionally undocumented.
* Merge the second y_bit check into the first one where it belongstb2022-11-241-5/+5
| | | | suggested by jsing
* Simplify y_bit handling in compressed coordinatestb2022-11-241-15/+2
| | | | | | | | If y_bit is set for a zero y, something is wrong and we can error directly. No need to run the non-trivial BN_kronecker() to check if BN_mod_sqrt() lied or not, only to set a more specific error code. ok jsing
* Clean up EC_METHOD and EC_GROUP definitionstb2022-11-241-102/+111
| | | | | | | Remove obvious comments, wrap long lines and general KNF cleanup. Format and rephrase the more important comments. Discussed with jsing
* Change bn_expand()/bn_wexpand() to indicate failure/success via 0/1.jsing2022-11-2415-83/+83
| | | | | | | | | Currently bn_expand()/bn_wexpand() return a BIGNUM *, however none of the callers use this (and many already treat it as a true/false value). Change these functions to return 0 on failure and 1 on success, revising callers that test against NULL in the process. ok tb@
* Call bn_expand() rather than handrolling an equivalent.jsing2022-11-241-5/+5
| | | | | | | The current code manually calculates words from bits and then calls bn_wexpand() - call bn_expand() with bits instead. ok tb@
* Fix sparc64 build/runkn2022-11-231-3/+2
| | | | | | constraints.c:269: warning: ISO C90 forbids mixed declarations and code from tb
* Add void casts since gcc 4.2.1 on sparc64 doesn't like the missing returntb2022-11-231-5/+5
| | | | checks for BIO_reset().
* Several improvements required for <openssl/bn.h>:schwarze2022-11-231-26/+39
| | | | | | | | | | * List internal constants and types that are intentionally undocumented. * List unused constants and types that are intentionally undocumented. * Cope with intentionally undocumented identifiers being declared more than once (in this case, because of #if and #else). * Require exact matches for man -k searches (in this case, such that BN_BITS does not match BN_BITS2). * Handle the weird BN_ULONG, which is #define'd instead of using typedef.
* Make a stupid compiler on a stupid OS happy.tb2022-11-231-1/+2
| | | | from bcook
* bn_unit: appease coveritytb2022-11-231-2/+6
| | | | | | | Apparently, the '0' in memset(a, '0', size - 1); could be a typo for '\0'. Randomize the decimal digit to make the intent clear. CID 377009
* asn1_string_to_utf8 test: appease coveritytb2022-11-231-2/+8
| | | | | | | | | | Check for ASN_STRING_to_UTF8() failure before checking it matches our expectations. This should convey clearly that test->want_len is never negative. CID 377011 Diagnosed by jsing
* Neuter getrlimit dance, it's not portable enough. Stupid Windows.tb2022-11-231-14/+4
|
* Fix leaks in ecx_set_{priv,pub}_key()tb2022-11-231-9/+9
| | | | | | | | When ecx_key_set_{priv,pub}() fails, ecx_key is leaked. CID 377014 From jsing
* Reverse arguments in CBS_dup()tb2022-11-231-2/+2
| | | | | | | | We want to copy the tls_content_cbs() into the cbs, not the other way around CID 377013 ok jsing
* Fix inconsequential copy-paste errortb2022-11-231-3/+3
| | | | CID 377010
* Use bn_wexpand() rather than bn_expand() with sizeof(BN_ULONG).jsing2022-11-232-4/+4
| | | | | | | This also fixes a bug in BN_MONT_CTX_set(), where the sizeof(BN_ULONG) in the call to bn_expand() was not multiplied by eight (to get bits). ok tb@
* Ensure that bn_expand()/bn_wexpand() fail on negative sizes.jsing2022-11-231-1/+7
| | | | ok tb@
* Turn bn_wexpand() into a function.jsing2022-11-232-5/+13
| | | | | | | | Any sensible compiler will likely inline this anyway (and even if it does not, one extra function call/return is the least of the performance overhead for this code). ok tb@
* Move bn_expand() under bn_expand2().jsing2022-11-231-13/+13
| | | | | | No functional change. ok tb@
* Remove unused bn_dup_expand().jsing2022-11-232-56/+2
| | | | ok tb@
* Move #ifndef OPENSSL_NO_DEPRECATED.jsing2022-11-231-21/+21
| | | | | | | The BN_set_params()/BN_get_params() and associated unused variables are meant to be in this block, not things like BN_new() and BN_free(). ok tb@
* Remove bn_* defines/prototypes.jsing2022-11-231-4/+1
| | | | | | These now come directly via bn_lcl.h. ok tb@
* Fix some whitespace and comment formattingtb2022-11-221-37/+45
|
* Rename last OPENSSL_gmtime() to asn1_time_time_t_to_tm()tb2022-11-221-2/+2
| | | | | | | This rename was done before commit, but one instance was missed since it was hidden behind #ifdef SMALL_TIME_T. Spotted by Android CI.
* Remove incorrect "r must not be a" commenttb2022-11-221-2/+1
| | | | | This was fixed by Eric A. Young in "a C2Net version of SSLeay" and committed to OpenSSL by Mark J. Cox in January 1999 (OpenSSL a0a54079).
* Plug leaks spotted by ASAN CItb2022-11-221-1/+3
|
* mention what BN_ULONG isschwarze2022-11-223-8/+33
|
* Remove the lie that BN_ULONG might be 16 bits wide.schwarze2022-11-221-9/+11
| | | | | | We don't install this page, but it might possibly still help developers working on internals of the BN library, so i'm not in a hurry to cvs rm this file.
* Better document BN_ULONG (in the DESCRIPTION near BN_num_bits_word(3))schwarze2022-11-221-40/+84
| | | | | | | | | | | and BN_BITS2 (below RETURN VALUES). While here, perform major reordering and rewriting for precision and readability, in particular: - Avoid misleading wordings like "size of a BIGNUM". - Drop the trivial example. - Move the pointers to RSA_size(3) and friends to CAVEATS. - Stop recommending 8*BN_num_bytes() in this context because it is wrong, too.
* Remove comment obsoleted by API change (and r1.3)tb2022-11-221-2/+1
|
* ed25519 test: make the testvectors table consttb2022-11-221-4/+4
|
* simplify makefileanton2022-11-221-8/+2
|
* Be more helpful and provide details on what the time conversion testsanton2022-11-221-9/+6
| | | | | | need in order to run. Also, output the expected SKIPPED string as dictated by bsd.regress.mk.
* Tweak a printf.tb2022-11-221-3/+3
|
* Add a unit test that crashes without bn_print.c r1.34.tb2022-11-222-1/+95
|
* Fix segfaults in BN_dec2bn() and BN_hex2bn()tb2022-11-221-3/+3
| | | | | | | | | bn_print.c r1.29 added length checks to avoid overflowing the BIGNUM. If these checks are hit in length-only mode, i.e., bn is NULL, the error path dereferences bn. Change goto err to an early return to avoid this. ok jsing
* document BN_nist_mod_521(3) and their four siblingsschwarze2022-11-213-3/+118
|
* Fix a surprising quirk in BN_GF2m_mod(3).schwarze2022-11-202-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | All other wrappers in the same file that use a temporary array of degrees size that array dynamically, such that they are able to handle reducing polynomials of arbitrary lengths. BN_GF2m_mod(3) was the only one that used a static array of size 6 instead, limiting it to trinomials and pentanomials and causing it to fail for longer reducing polynomials. Make this more uniform and less surprising by using exactly the same code as in all the other wrappers, such that BN_GF2m_mod(3) works with reducing polynomials of arbitrary length, too, just like the others. Again, tb@ points out this quirk is very unlikely to cause vulnerabilities in practice because cryptographic applications do not use longer reducing polynomials. This patch is not expected to significantly impact performance because the relevant caller, BN_GF2m_mod_div(3), already uses dynamic allocation via BN_GF2m_mod_mul(3). OK tb@
* Fix an off-by-one bug in BN_GF2m_poly2arr(3).schwarze2022-11-201-4/+3
| | | | | | | | | | | | | | | | | | | | | If the last argument, the size of the output array, is too small to contain all degrees present in the input polynomial plus one for the terminating -1, the function is documented to return the size of the output array that would be needed (in comments in the source code, in the new manual page, and by the way how the function is used by other functions in the same file). However, in case of overflow, the existing code failed to include the element needed for the terminating -1 in the return value, wrongly indicating success if everything but the -1 did fit and reporting failure with a size that was still too small otherwise. According to tb@, this is very unlikely to cause vulnerabilities in practical applications because there is no real reason to pick a reducing polynomial longer than a pentanomial, because all known callers use either fixed size arrays of size 6 or dynamic allocation, because use of GF(2^m) is rare in practice, and GF(2^m) with custom reducing polynomials even more so. OK tb@