summaryrefslogtreecommitdiff
path: root/src/lib (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Add a small blurb on @SECLEVEL=nlibressl-v3.7.0tb2022-12-111-2/+8
|
* Fix copy-paste error that left a paragraph ending in a commatb2022-12-081-3/+3
|
* Improve the implementation of BIO_push(3) such that it changes nothingschwarze2022-12-072-6/+39
| | | | | | and reports failure if a call would result in a cycle. The algorithm used was originally suggested by jsing@. Feedback and OK tb@.
* Add references to the BIO_{push,pop}(3) exampletb2022-12-071-3/+8
| | | | | | | | | The reader may not know what digest BIOs, Base64 BIOs and file BIOs are and the relevant function names are non-obvious, hence it's not entirely trivial to find the manuals where they are explained. With these references a reader should be able to turn the example into actual code. ok schwarze
* Fix example stringtb2022-12-071-4/+4
| | | | | | If you want to Base64-encode "Hello World\n" using a BIO, you had better pass "Hello World\n" into it, not something slightly different... While we're touching this, we might as well write it the way K&R did...
* Zap extra spacetb2022-12-061-3/+3
|
* Major rewrite for accuracy and clarity, and document BIO_set_next(3).schwarze2022-12-061-37/+148
| | | | Feedback and OK tb@.
* Make sure BIO_push(3) always preserves all invariants of the prev_bioschwarze2022-12-061-3/+10
| | | | | | | | | | | | | | | | | | | | and next_bio fields of all BIO objects in all affected chains, no matter what the arguments are. In particular, if the second argument (the one to be appended) is not at the beginning of its chain, properly detach the beginning of its chain before appending. We have weak indications that this bug might affect real-world code. For example, in FreeRDP, file libfreerdp/crypto/tls.c, function bio_rdp_tls_ctrl(), case BIO_C_SET_SSL, BIO_push(3) is definitely called with a second argument that is *not* at the beginning of its chain. Admittedly, that code is hard to fathom, but it does appear to result in a bogus prev_bio pointer without this patch. The practical impact of this bug in this and other software remains unknown; the consequences might possibly escalate up to use-after-free issues if BIO_pop(3) is afterwards called on corrupted BIO objects. OK tb@
* Improve the poorly designed BIO_set_next(3) API to always preserve allschwarze2022-12-061-3/+18
| | | | | | | | | | | | | | | | | invariants of the prev_bio and next_bio fields of all BIO objects in all involved chains, no matter which arguments this function is called with. Both real-world uses of this function (in libssl and freerdp) have been audited to make sure this makes nothing worse. We believe libssl behaves correctly before and after the patch (mostly because the second argument is NULL there), and we believe the code in freerdp behaves incorrectly before and after the patch, leaving a prev_bio pointer in place that is becoming bogus, only in a different object before and after the patch. But after the patch, that bogus pointer is due to a separate bug in BIO_push(3), which we are planning to fix afterwards. Joint work with and OK tb@.
* arithmethic -> arithmeticjsg2022-12-061-3/+3
|
* Drop 'perhaps a little', plus grammar and spelling nitstb2022-12-021-5/+5
| | | | | BIO_push() and BIO_pop() are misnamed. No need to gently and politely suggest that their 'names [...] are perhaps a little misleading'.
* Revert bio_prev removaltb2022-12-022-2/+12
| | | | | | | | | As schwarze points out, you can pop any BIO in a chain, not just the first one (bonus points for a great name for this API). The internal doubly linked was used to fix up the BIO chain bio was part of when you BIO_pop() a bio that wasn't in the first position, which is explicitly allowed in our documentation and implied by OpenSSL's.
* Update reference to table generationtb2022-12-011-2/+2
|
* Mark the X509_V_FLAG_CB_ISSUER_CHECK flag as deprecatedtb2022-12-011-11/+5
|
* Annotate X509_V_FLAG_CB_ISSUER_CHECK as deprecated and unusedtb2022-12-011-3/+3
|
* Retire X509_V_FLAG_CB_ISSUER_CHECKtb2022-12-011-16/+8
| | | | | | | | | This flag has been deprecated in OpenSSL 1.1 and has not had an effect since. This way we can simplify the default check_issued() callback, which helpfully has its arguments reversed compared to the public API X509_check_issued(). ok jsing
* Getters and setters for the check_issued() callbacktb2022-12-013-3/+39
| | | | | | | | | | | | | | | Open62541 uses X509_STORE_CTX_get_check_issued(), so provide it along with X509_STORE_{get,set}_check_issued(). As you would expect, they all return or take an X509_STORE_CTX_check_issued_fn. The getters aren't const in OpenSSL 1.1, but they now are in OpenSSL 3... These will be made available in the next minor bump and will ship in the stable release of LibreSSL 3.7 Part of OpenSSL commit 1060a50b See also https://github.com/libressl-portable/portable/issues/748 ok beck jsing
* BN_one() can fail, check its return value.jsing2022-12-012-9/+16
| | | | ok tb@
* Rewrite bn_correct_top().jsing2022-11-302-14/+10
| | | | | | | bn_correct_top() is currently a macro and far more complex than it needs to be - rewrite it as a function. ok tb@
* Fix return values bug in BN_ucmp().jsing2022-11-301-4/+6
| | | | | | | | BN_ucmp() is supposed to return -1/0/1 on a < b, a == b and a > b, however it currently returns other negative and positive values when the top of a and b differ. Correct this. ok tb@
* Mostly align BIO_read()/BIO_write() return values with OpenSSL 3.x.jsing2022-11-301-7/+21
| | | | | | | | | | For various historical reasons, there are a number of cases where our BIO_read() and BIO_write() return slightly different values to what OpenSSL 3.x does (of course OpenSSL 1.0 differs from OpenSSL 1.1 which differs from OpenSSL 3.x). Mostly align these - some further work will be needed. Issue raised by tb@ who also wrote some test code.
* Mop up more BN_DEBUG related code.jsing2022-11-307-48/+7
|
* Add missing markup to comments and to RFC 3779 errortb2022-11-291-10/+12
|
* First pass at updating verifier error docstb2022-11-291-13/+41
| | | | | | | | | | X509_verify_cert_error_string() is now thread safe as it no longer returns a static buffer. Document X509_V_ERR_UNSPECIFIED. Stop asserting that the X509_V_ERR_CERT_CHAIN_TOO_LONG code is unused, the new verifier can set it. Add commented versions of various missing error codes in the proper spots and move X509_V_ERR_UNNESTED_RESOURCE where it belongs. prompted by claudio
* Remove a few doubled spaces and wrap an overlong linetb2022-11-291-8/+9
|
* Sort a few outliers by increasing error number to match x509_vfy.htb2022-11-291-13/+13
|
* Fix includestb2022-11-291-11/+2
| | | | | No need for errno, stdio, time, asn1, buffer, evp, lhash, objects, x509 for a switch containing string constants. We do need x509_vfy instead.
* Add missing X509_V_ERR_UNSPECIFIED casetb2022-11-291-1/+3
|
* Fix some KNF issuestb2022-11-291-65/+64
| | | | Requested by claudio
* Make X509_verify_cert_error_string() thread safetb2022-11-291-5/+2
| | | | | | | Stop returning a pointer to a static buffer containing the error code on unknown error. While this might be helpful, it's not going to end well. ok beck claudio jsing
* Garbage collect the unused asn1_add_error()tb2022-11-281-7/+1
| | | | ok jsing
* Retire prev_biotb2022-11-282-12/+2
| | | | | | | | | | | | | While BIO chains are doubly linked lists, nothing has ever made use of this fact internally. Even libssl has failed to maintain prev_bio properly in two places for a long time. When BIO was made opaque, the opportunity to fix that was missed. Instead, BIO_set_next() now allows breaking the lists from outside the library, which freerdp has long done. Problem found by schwarze while trying to document BIO_set_next(). schwarze likes the idea ok jsing
* 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-26426-932/+1498
| | | | | | | | | | | | | | | | 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.
* 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@.
* 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 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
* 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@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-05-01 11:01:03 +0000