A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=OPENBSD_7_9 2025-05-10T05:54:39+00:00 2025-05-10T05:54:39+00:00 tb 2025-05-10T05:54:39+00:00 urn:sha1:41e8f99dd1625a9f0c80ce9d4383e95b18e85709 ok jsing 2024-12-20T20:05:29+00:00 schwarze 2024-12-20T20:05:29+00:00 urn:sha1:9588bf96d4ac4c99af7b3764a6671ddb6201ca2c with an unsupported control command, return -1 rather than 0 to the caller to indicate the error because in general, these control hooks ought to return -1 for unsupported control commands and 0 for other errors, for example other invalid arguments. Not a big deal because this change does not change when operations succeed or fail, and because callers are unlikely to pass unsupported control commands in the first place. The only functional change is that if a calling program inspects the ERR(3) stack after this failure, it will now find the correct error code rather than nothing. Even that wasn't a huge problem because for most EVP_CIPHER control failures, getting no reason for the error is the usual situation. Then again, giving the reason when easily possible may occasionally be useful. OpenSSL also returns -1 in this case, so it also helps compatibility a tiny bit. Found while auditing the return values of all the EVP_CIPHER control hooks in our tree. This was the only fishy one i found. OK tb@ 2024-05-22T14:02:08+00:00 tb 2024-05-22T14:02:08+00:00 urn:sha1:bdfe60b31e70aaf6fe4dee70a0e08e1b14d96233 Take the MAC before clobbering the input value on decryption. Fixes hangs during the QUIC handshake with HAProxy using TLS_CHACHA20_POLY1305_SHA256. Found, issue pinpointed, and initial fix tested by Lucas Gabriel Vuotto: Let me take this opportunity to thank the HAProxy team for going out of their way to keep supporting LibreSSL. It's much appreciated. See https://github.com/haproxy/haproxy/issues/2569 tweak/ok jsing 2024-04-09T13:52:42+00:00 beck 2024-04-09T13:52:42+00:00 urn:sha1:9835bb3c82adc630df1f3aaa7dfbf7f0506b0bc4 largely mechanically done by the guentherizer 9000 ok tb@ 2023-12-30T18:24:09+00:00 tb 2023-12-30T18:24:09+00:00 urn:sha1:4c4f3bc8ce76bae155c4f1dfe311d3444e35b3ec 2023-12-15T13:48:59+00:00 tb 2023-12-15T13:48:59+00:00 urn:sha1:51088b62ca9f22f2160fa0ce90bdd0441e8178dd On overlong input, chacha20_poly1305_cipher() would return 0, which in EVP_CipherUpdate() and EVP_CipherFinal() signals success with no data written since EVP_CIPH_FLAG_CUSTOM_CIPHER is set. In order to signal an error, we need to return -1. Obviously. ok jsing 2023-09-28T11:29:10+00:00 tb 2023-09-28T11:29:10+00:00 urn:sha1:51b553d9a746433693f625d3f21184da15e95972 In today's episode of "curly nonsense from EVP land" we deal with a quite harmless oversight and a not too bad suboptimal fix, relatively speaking. At some point EVP_CIPHER_{CCM,GCM}_SET_IVLEN was added. It modified some object hanging off of EVP_CIPHER. However, EVP_CIPHER_CTX_iv_length() wasn't taught about this and kept returning the hardcoded default value on the EVP_CIPHER. Once it transpired that a doc fix isn't going to cut it, this was fixed. And of course it's easy to fix: you only have to dive through about three layers of EVP, test and set a flag and handle a control in a couple methods. The upstream fix was done poorly and we begrudgingly have to match the API: the caller is expected to pass a raw pointer next to a 0 length along with EVP_CIPHER_GET_IV_LENGTH and the control handler goes *(int *)ptr = length in full YOLO mode. That's never going to be an issue because of course the caller will always pass a properly aligned pointer backing a sufficient amount of memory. Yes, unlikely to be a real issue, but it could have been done with proper semantics and checks without complicating the code. But why do I even bother to complain? We're used to this. Of note here is that there was some pushback painting other corners of a bikeshed until the reviewer gave up with a resigned That kind of changes the semantics and is one extra complexity level, but [shrug] ok... Anyway, the reason this matters now after so many years is that rust-openssl has an assert, notably added in a +758 -84 commit with the awesome message "Docs" that gets triggered by recent tests added to py-cryptography. Thanks to Alex Gaynor for reporting this. Let me take the opportunity to point out that pyca contributed to improve rust-openssl, in particular its libressl support, quite a bit. That's much appreciated and very noticeable. Regress coverage to follow in subsequent commits. Based on OpenSSL PR #9499 and issue #8330. ok beck jsing PS: A few macros were kept internal for now to avoid impact on the release cycle that is about to finish. They will be exposed after release. 2023-08-24T04:33:08+00:00 tb 2023-08-24T04:33:08+00:00 urn:sha1:41881d1899bdc5c08e89d538fcff40cd5ce959cf RFC 7539 was superseded by RFC 8439, incorporating errata and making editorial improvements. Very little of substance changed, in particular section numbers remain the same. Prompted by a question from schwarze 2023-07-07T19:37:54+00:00 beck 2023-07-07T19:37:54+00:00 urn:sha1:1ca8095297adf80b48019b5a2d18010ff9e3427f me aliasing symbols not in the headers I was procesing. This unbreaks the namespace build so it will pass again ok tb@ 2023-07-07T13:54:46+00:00 beck 2023-07-07T13:54:46+00:00 urn:sha1:f9fcde20a6214da85e802190ccd3a2bf5f891559 (part 2 of commit) ok jsing@