A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.8.0 2023-05-14T16:36:25+00:00 2023-05-14T16:36:25+00:00 tb 2023-05-14T16:36:25+00:00 urn:sha1:816eddcf8128dfb5e2e9a4c68c07f2ca97df1275 *) 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... 2023-03-15T06:14:02+00:00 tb 2023-03-15T06:14:02+00:00 urn:sha1:3bd54020171e9b2e7330ee5ed831533a5344cee8 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 2022-12-26T07:18:53+00:00 jmc 2022-12-26T07:18:53+00:00 urn:sha1:2eb7e5ff6bb69760f9dd4a43e7e3520ebb930120 i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb 2022-12-22T20:13:45+00:00 schwarze 2022-12-22T20:13:45+00:00 urn:sha1:31cda01b7fefa09cc90d191b204f3b15cea70c62 OK tb@ 2022-12-16T13:41:55+00:00 schwarze 2022-12-16T13:41:55+00:00 urn:sha1:276664d6605ecf92a3b35c4f8c22ebec09a912c1 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. 2022-12-07T23:08:47+00:00 schwarze 2022-12-07T23:08:47+00:00 urn:sha1:eab11350130a507ed42936e4a3c922f3930a163e and reports failure if a call would result in a cycle. The algorithm used was originally suggested by jsing@. Feedback and OK tb@. 2022-12-06T17:59:21+00:00 schwarze 2022-12-06T17:59:21+00:00 urn:sha1:3b64f394bc39450f6bc4bd64ecff7d97d8f0ddb7 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@ 2022-12-06T16:10:55+00:00 schwarze 2022-12-06T16:10:55+00:00 urn:sha1:acd6804e79b3e295f377e2b130890a08aafc3c2f 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@. 2022-12-02T19:44:04+00:00 tb 2022-12-02T19:44:04+00:00 urn:sha1:a24e48fc0fa4c6c759985c014000574a65d4d0a8 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. 2022-11-30T01:56:18+00:00 jsing 2022-11-30T01:56:18+00:00 urn:sha1:91315cb3be072462af759c6d8f63e0611eacd0e2 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.