A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v4.1.2 2025-02-04T04:51:34+00:00 2025-02-04T04:51:34+00:00 tb 2025-02-04T04:51:34+00:00 urn:sha1:73114f7e34f45afd0e7f8eea84b606ba93a106ff CID 532326 ok djm jsing 2025-01-20T12:57:28+00:00 tb 2025-01-20T12:57:28+00:00 urn:sha1:1737b7a21404e79b547997d636147775a9ce091e 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-09-06T09:57:32+00:00 tb 2024-09-06T09:57:32+00:00 urn:sha1:de922e906737ea318d3a84723ec68b62581dd51c The OPENSSL_cpu_caps() change after the last bump missed a crucial bit: there is more MD mess in the MI code than anticipated, with the result that AES is now used without AES-NI on amd64 and i386, hurting machines that previously greatly benefitted from it. Temporarily add an internal crypto_cpu_caps_ia32() API that returns the OPENSSL_ia32cap_P or 0 like OPENSSL_cpu_caps() previously did. This can be improved after the release. Regression reported and fix tested by Mark Patruck. No impact on public ABI or API. with/ok jsing PS: Next time my pkg_add feels very slow, I should perhaps not mechanically blame IEEE 802.11... 2024-08-31T10:38:49+00:00 tb 2024-08-31T10:38:49+00:00 urn:sha1:74a335fca70cbc1c69a8939c41ad12d0a6414a99 It's just gross. Only used by a popular disk encryption utility on an all-too-popular OS one or two decades back. ok beck jsing 2024-08-31T10:25:38+00:00 tb 2024-08-31T10:25:38+00:00 urn:sha1:1879b1c335b79500e4608d064e6a67c172898224 I ranted enough about this recently. PKCS#12. Microsoft. 'nuff said. ok beck jsing 2024-08-31T09:14:21+00:00 tb 2024-08-31T09:14:21+00:00 urn:sha1:4d0ecb9ca6915541794e3cc736907b89e9a1dd6c This API turned out to be a really bad idea. OpenSSL 3 extended it, with the result that basically every key type had its own DoS issues fixed in a recent security release. We eschewed these by having some upper bounds that kick in when keys get insanely large. Initially added on tobhe's request who fortunately never used it in iked, this was picked up only by ruby/openssl (one of the rare projects doing proper configure checks rather than branching on VERSION defines) and of course xca, since it uses everything it can. So it was easy to get rid of this again. ok beck jsing 2024-08-29T16:58:19+00:00 tb 2024-08-29T16:58:19+00:00 urn:sha1:c8099c070f0c547b73edced83591dbd871254307 This disables the EVP_PKEY_*check() API and makes it fail (more precisely indicate lack of support) on all key types. This is an intermediate step to full removal. Removal is ok beck jsing 2024-08-28T07:15:04+00:00 tb 2024-08-28T07:15:04+00:00 urn:sha1:f822543d6a7043acc1d14a3e0b44eddc1051b097 This is a slightly strange combination of OBJ_find_sigid_algs() and the security level API necessary because OBJ_find_sigid_algs() on its own isn't smart enough for the special needs of RSA-PSS and EdDSA. The API extracts the hash's NID and the pubkey's NID from the certificate's signatureAlgorithm and invokes special handlers for RSA-PSS and EdDSA for retrieving the corresponding information. This isn't entirely free for RSA-PSS, but for now we don't cache this information. The security bits calculation is a bit hand-wavy, but that's something that comes along with this sort of numerology. ok jsing 2024-08-22T12:24:24+00:00 tb 2024-08-22T12:24:24+00:00 urn:sha1:fc0702d8720a97dcf11b0e1241a3245bf18fcb95 ok miod