summaryrefslogtreecommitdiff
path: root/src/regress/lib/libcrypto/dsa/dsatest.c
diff options
context:
space:
mode:
authortb <>2023-09-28 11:29:10 +0000
committertb <>2023-09-28 11:29:10 +0000
commit92da04b3fa82724d71f293483fb9284e6da2fa37 (patch)
tree3522ab66513de919b4cb23f4f9a24a55b2df8066 /src/regress/lib/libcrypto/dsa/dsatest.c
parenta95a07cea06fc8d354ce9de8b80ef4f91fbfe23c (diff)
downloadopenbsd-92da04b3fa82724d71f293483fb9284e6da2fa37.tar.gz
openbsd-92da04b3fa82724d71f293483fb9284e6da2fa37.tar.bz2
openbsd-92da04b3fa82724d71f293483fb9284e6da2fa37.zip
Fix EVP_CIPHER_CTX_iv_length()
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.
Diffstat (limited to 'src/regress/lib/libcrypto/dsa/dsatest.c')
0 files changed, 0 insertions, 0 deletions