summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/bio (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove BIO_s_log() prototype, pointed out by schwarzetb2025-07-161-14/+13
|
* Remove bss_log.c: no longer linked to buildtb2025-07-161-216/+0
|
* correct indentation, no functional changejsg2025-06-022-7/+8
| | | | found with smatch, ok tb@
* Plug leak of bm->buf->datatb2025-05-311-1/+2
| | | | | BIO_new(BIO_s_mem()) now allocates this pointer, so we need to free it before assigning to it.
* Create bm->buf from the start to avoid arithmetic on NULLtb2025-05-241-1/+7
| | | | | | | | | This is a different way of avoiding the pointer arithmetic on NULL and avoids test breakage in pyca/cryptography. This is also a gross hack that penalizes existing callers of BIO_s_mem(), but this is rarely called in a hot loop and if so that will most likely be a test. ok kenjiro joshua jsing
* Revert "bio_mem: avoid pointer arithmetic on NULL"tb2025-05-241-4/+2
| | | | This causes a test failure in pyca/cryptography.
* bio_mem: avoid pointer arithmetic on NULLtb2025-05-181-2/+4
| | | | | | Prompted by a diff by Kenjiro Nakayama ok jsing
* Use err_local.h rather than err.h in most placestb2025-05-1010-20/+19
| | | | ok jsing
* bss_log.c: don't rely on err.h pulling in bio.htb2025-05-091-2/+2
| | | | ok jsing
* Hide symbols for two missed public functions in bio.hbeck2024-07-092-2/+4
| | | | ok tb@
* libcrypto: constify most error string tablestb2024-06-241-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | These constitute the bulk of the remaining global mutable state in libcrypto. This commit moves most of them into data.rel.ro, leaving out ERR_str_{functs,libraries,reasons} (which require a slightly different approach) and SYS_str_reasons which is populated on startup. The main observation is that if ERR_load_strings() is called with a 0 lib argument, the ERR_STRING_DATA argument is not actually modified. We could use this fact to cast away const on the caller side and be done with it. We can make this cleaner by adding a helper ERR_load_const_strings() which explicitly avoids the assignment to str->error overriding the error code already set in the table. In order for this to work, we need to sprinkle some const in err/err.c. CMS called ERR_load_strings() with non-0 lib argument, but this didn't actually modify the error data since it ored in the value already stored in the table. Annoyingly, we need to cast const away once, namely in the call to lh_insert() in int_err_set_item(). Fixing this would require changing the public API and is going to be tricky since it requires that the LHASH_DOALL_FN_* types adjust. ok jsing
* remove prototypes with no matching functionjsg2024-05-191-10/+1
| | | | feedback and ok tb@
* bss_conn: zap trailing whitespacetb2024-04-191-8/+8
|
* Move BIO_CONNECT_{new,free}() to internal-onlytb2024-04-151-5/+5
| | | | ok jsing
* Unify *_up_ref() implementationstb2024-03-271-3/+2
| | | | | | No need for an inconsistently named local variable and a ternary operator. ok jsing
* Remove BIO_set()tb2024-03-022-11/+2
| | | | | | | This used to be a dangerous implementation detail of BIO_new() that was never used outside of libcrypto. ok jsing
* Remove BIO_dump_*{cb,fp}()tb2024-03-022-44/+4
| | | | | | | These were disabled and the internals that need to remain were fixed. Time for this garbage to go. ok jsing
* Remove BIO_{sn,v,vsn}printf(3)tb2024-03-023-72/+11
| | | | | | | Unsued printing functionality. If something should need this we can readily add it back. ok jsing
* Use calloc() instead of malloc() in BIO_new().jsing2024-02-171-16/+5
| | | | ok tb@
* Inline and disable BIO_set().jsing2024-02-161-21/+19
| | | | | | | | BIO_set() is a dangerous function that cannot be used safely. Thankfully, the only consumer is BIO_new(), hence inline the functionality and disable the BIO_set() function (for complete removal in the near future). ok tb@
* Use 'bio' more consistently for function arguments.jsing2024-02-161-58/+61
| | | | | | | | Rather than 'a' or 'b', use 'bio' more consistently - there are still some more complex cases that have been left alone for now. Also use fewer parentheses. No change to generated assembly other than line numbers.
* BIO_dump*() avoid signed integer overflowtb2024-02-151-1/+10
| | | | | | | | | This API returns an int encoding the number of bytes printed. Thus, a dump of a large enough byte string can make this overflow and rely on undefined behavior. With an indent of 64, as little as 26 MB is enough to make this happen. ok jsing
* Reimplement BIO_dump_indent() with CBS/CBB and BIO_printf()tb2024-02-021-64/+115
| | | | | | | | | | | | | Instead of heaps of unchecked strlcpy/strlcat/snprintf doing hard to follow gymnastics, use a byte string, a somewhat comprehensible computation of the number of bytes to dump per output line and write using checked BIO_printf() directly to the BIO. Longer strings will still overflow the terminal width of 80 and even longer strings will still overflow the return value (undefined behavior). I don't care much about the former but the latter should be fixed in a later pass. ok beck
* Prepare to remove the _cb() and _fp() versions of BIO_dump()tb2024-02-011-33/+30
| | | | | | | | | | | | | apache-httpd uses BIO_dump(), libssl uses BIO_dump_indent(), and the openssl(1) app uses both. Otherwise this is unused. This is horribly bad code even by libcrypto standards. By doing away with the callbacks fixes incorrect error checking for fwrite() but there is a lot more wrong in here. This can be cleaned up in a later pass, the only concern here is to be able to remove the unused variants in the next major bump. ok beck
* KNF, no assembly changeschwarze2023-08-251-13/+9
| | | | OK tb@ jsing@
* Fix two leaks in BIO_dup_chain()tb2023-08-071-19/+17
| | | | | | | | If CRYPTO_dup_ex_data() fails, the new_bio is leaked. If an error occurs after the first iteration, all members of the new chain except the head are leaked. ok jsing
* Add missing space before =tb2023-08-071-2/+2
|
* reinstate KNF for commenttb2023-07-291-2/+2
|
* Drop BIO_n{read,write}{,0}()tb2023-07-281-255/+2
| | | | | | | | | | | | | | | | | | This is one of those strange things that should never have made it into a security-oriented libraries. From BIO_s_bio.3: .\" The following non-copying I/O functions are intentionally undocumented .\" because they seem fragile and unused by anything: It was used in a single place: the gorgeous ssltest. I'm not smart enough to follow. Also: /* WARNING: The non-copying interface is largely untested as of yet * and may contain bugs. */ Oh, really? Into the great bitbucket in the sky you go. ok jsing
* Make ASN.1 BIO internaltb2023-07-281-16/+1
| | | | | | | | | | | | With every bump we can remove a bit more of the ASN.1 BIO and the streaming interface. At some point enough will be internal so that we can rewrite it and bring it in a shape where mere mortals can follow all the twists and turns. This is the next step: BIO_f_asn1(3) goes away and takes BIO_asn1_{get,set}_{prefix,suffix}() with it, a bunch of functions helping along in a write-after-free recently. The getters go away, the setters stay for now. ok jsing
* BIO_indent: use %*s rather than puts in a looptb2023-07-101-6/+5
| | | | ok beck jsing millert
* Unbreak the namespace build after a broken mk.conf and tool misfire hadbeck2023-07-074-10/+4
| | | | | | | | me aliasing symbols not in the headers I was procesing. This unbreaks the namespace build so it will pass again ok tb@
* Hide symbols in asn1 and biobeck2023-07-0521-24/+149
| | | | ok jsing@
* Merge bio.h patch from libressl-portabletb2023-07-051-1/+15
| | | | ok beck@
* Correct formattingbeck2023-07-051-17/+9
| | | | ok jsing@
* Send the linebuffer BIO to the attictb2023-05-141-377/+0
| | | | | | | | | | | | | | | | | | | | | *) On VMS, stdout may very well lead to a file that is written to in a record-oriented fashion. That means that every write() will write a separate record, which will be read separately by the programs trying to read from it. This can be very confusing. The solution is to put a BIO filter in the way that will buffer text until a linefeed is reached, and then write everything a line at a time, so every record written will be an actual line, not chunks of lines and not (usually doesn't happen, but I've seen it once) several lines in one record. BIO_f_linebuffer() is the answer. Currently, it's a VMS-only method, because that's where it has been tested well enough. [Richard Levitte] Yeah, no, we don't care about any of this and haven't compiled this file since forever. Looks like tedu's chainsaw got blunt at some point...
* Streaming BIOs assume they can write to NULL BIOstb2023-03-151-5/+4
| | | | | | | | | | At least SMIME_text() relies on this. Pushing an error on the stack trips PKCS7 regress in py-cryptography, so indicate nothing was written instead of throwing an error. Reported by Alex Gaynor a while back ok jsing
* spelling fixes; from paul tagliamontejmc2022-12-261-2/+2
| | | | | | | i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb
* in case of failure, always report the error with BIOerror();schwarze2022-12-221-4/+14
| | | | OK tb@
* Revert BIO_push(3) cycle prevention (bio_lib.c rev. 1.42).schwarze2022-12-161-7/+1
| | | | | | | | | | | | | | | | | | | jsing@ worries that cycle prevention might increase risk because software that is not checking return values (and indeed, not checking is likely common in practice) might silently behave incorrectly with cycle prevention whereas without, it will likely either crash right away through infinite recursion or at least hang in an infinite loop when trying to use the cyclic chain, in both cases making it likely that the bug will be found and fixed. Besides, tb@ points out that BIO_set_next(3) ought to behave as similarly as possible to BIO_push(3), but adding cycle prevention to BIO_set_next(3) would be even less convincing because that function does not provide a return value, encouraging users to expect that it will always succeed. While a safe idiom for checking the success of BIO_set_next(3) could easily be designed, let's be realistic: application software would be highly unlikely to pick up such an idiom.
* Improve the implementation of BIO_push(3) such that it changes nothingschwarze2022-12-071-1/+7
| | | | | | and reports failure if a call would result in a cycle. The algorithm used was originally suggested by jsing@. 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@.
* 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.
* 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.
* 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
* Avoid potential divide by zero in BIO_dump_indent_cb()jsing2022-10-171-8/+7
| | | | | | | | | | | | | Passing an indent value of 67 results in DUMP_WIDTH_LESS_IDENT returning a value of zero, which is promptly used for division. Likewise, passing a value larger than 67 results in a negative value being returned. Prevent this by limiting indent to 64 (which matches OpenSSL's current behaviour), as well as ensuring that dump_width is > 0. Should fix oss-fuzz #52464 and #52467. ok miod@ tb@
* Make BIO_info_cb() identical to bio_info_cb()tb2022-09-111-2/+3
| | | | | | | | | | | | | Various projects use bio_info_cb and BIO_info_cb interchangeably, for example mupdf and freerdp. This is because this was changed in OpenSSL commit fce78bd4 (2017), triggered by new warnings in gcc 8. https://github.com/openssl/openssl/pull/4493 This results in some scary compiler warnings and useless patches in ports. Nobody seems to be using the old bio_info_cb() version. ok jsing
* Initialize readbytes in BIO_gets()tb2022-08-151-2/+2
| | | | | | | | If the bgets() callback returns <= 0, we currently rely on the user provided callback to set readbytes, which isn't ideal. This also matches what's done in BIO_read() and BIO_write(). ok jsing
* Remove mkerr.pl remnants from LibreSSLkn2022-07-122-12/+2
| | | | | | | This script is not used at all and files are edited by hand instead. Thus remove misleading comments incl. the obsolete script/config. Feedback OK jsing tb
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-07 11:48:08 +0000