summaryrefslogtreecommitdiff
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Unifdef ZLIBtb2023-06-117-739/+7
| | | | | | | This has long been unused code and compilation with -DZLIB was broken for a long time after BIO was made opaque. ok jsing
* Convert EVP_Digest{Sign,Verify}* to one-shot for TLSv1.3tb2023-06-102-22/+10
| | | | | | | Using one-shot EVP_DigestSign() and EVP_DigestVerify() is slightly shorter and is needed for Ed25519 support. ok jsing
* File new test-bleichenbacher-timing-pregenerate.py under failing teststb2023-06-101-1/+3
| | | | until someone finds time and motivation to figure out how to use this.
* Remove dead code.beck2023-06-081-13/+3
| | | | | | | | must_be_ca can no longer be 0 after the proxy cert code got nuked, so change this to an if. must_be_ca is now -1 for a leaf, or 1 for a non leaf. ok tb@
* From the description of "openssl verify", delete the duplicate andschwarze2023-06-081-130/+9
| | | | | | | outdated list of error messages. Instead, refer to the master copy of that list in X509_STORE_CTX_get_error(3). Suggested by and OK tb@, and beck@ also agrees with the idea.
* Add portable version and m88k-specific version lb() function, becauseaoyama2023-06-071-1/+21
| | | | | | unfortunately gcc3 does not have __builtin_clz(). ok miod@ otto@
* Refer to the field "thisUpdate" instead of the non-existent "lastUpdate".schwarze2023-06-071-4/+10
| | | | | Similar to X509_get0_notBefore(3) rev. 1.6. Requested by and OK tb@.
* In 1995, Eric A. Young chose a confusing name for the "lastUpdate" fieldschwarze2023-06-062-12/+20
| | | | | | | | | | | | | | | of the X509_CRL_INFO object. It should have been called "thisUpdate" like in RFC 5280 section 5.1 (and in its precursor RFC 2459). Then again, RFC 2459 was only published in 1999, so maybe the terminology wasn't firmly established yet when Young wrote his code several years earlier - just guessing, neither we nor the OpenSSL folks appear to know the real reasons... Anyway, we have been stuck with the "lastUpdate" names in the API for more than two decades now, so clarify in the documentation what they refer to and what they really mean. Requested by and OK tb@.
* Fix typo in comment: exta -> extratb2023-06-061-2/+2
|
* Fix copy+paste error in x509 asn regressjob2023-06-051-3/+3
|
* Improve the description of CMS_get0_signers()job2023-06-051-3/+3
| | | | | | | | | | Suggestion from Małgorzata Olszówka, they noted: "The original wording suggests that it is required to execute CMS_get0_signers() after CMS_verify(), while it is CMS_get0_signers() that requires prior successful invocation of CMS_verify()." OK tb@
* Reinstate bn_isqrt.c r1.8 and crypto_lock.c r1.3tb2023-06-042-8/+5
| | | | | | | | | | | | | | | This traded local copies of CTASSERT() to the one in crypto_internal.h. This change was backed out due to SHA-512 breakage on STRICT_ALIGNMENT architectures still using Fred Flintstone's gcc without asm sha512. Original commit message: Use crypto_internal.h's CTASSERT() Now that this macro is available in a header, let's use that version rather than copies in several .c files. discussed with jsing
* Make ruby-openssl cope with default ruby changetb2023-06-041-2/+2
|
* bn_mod_inverse tweakstb2023-06-041-2/+4
| | | | | Provide prototype that is hidden behind LIBRESSL_INTERNAL for portable and or in result for future extensibility.
* More thorough write-afetr-free checks.otto2023-06-043-25/+54
| | | | | | | | | | | | | | | | | | | On free, chunks (the pieces of a pages used for smaller allocations) are junked and then validated after they leave the delayed free list. So after free, a chunk always contains junk bytes. This means that if we start with the right contents for a new page of chunks, we can *validate* instead of *write* junk bytes when (re)-using a chunk. With this, we can detect write-after-free when a chunk is recycled, not justy when a chunk is in the delayed free list. We do a little bit more work on initial allocation of a page of chunks and when re-using (as we validate now even on junk level 1). Also: some extra consistency checks for recallocaray(3) and fixes in error messages to make them more consistent, with man page bits. Plus regress additions.
* Add regress coverage for BN_mod_inverse()tb2023-06-032-1/+387
| | | | | This would detect the aliasing issue reported by Guido Vranken fixed in bn_gcd.c r1.28. Most testcases are from BoringSSL's regress test.
* Fix variable reuse in BN_mod_inverse()tb2023-06-021-21/+15
| | | | | | | | | | | | | | | | | | The somewhat strange calculation m = a^{-1} (mod m) can return 0. This breaks because of BN_nnmod() having delicate semantics of which variable can be reused. BN_nnmod(a, a, m, ctx) works and the library relies on that. Here, the code ends up doing BN_nnmod(m, a, m, ctx) and this doesn't work. If the result of the initial BN_mod() is negative, then BN_nnmod() will return 0. Problem reported by Guido Vranken in https://github.com/openssl/openssl/issues/21110 This code is well covered by regress, but it does not currently have explicit test coverage. Such will be added soon. ok beck jsing
* fix typotb2023-06-021-2/+2
|
* Remove the speed test againtb2023-06-011-7/+2
| | | | | It takes too much time and we now know that all covered ciphers can cope with unaligned input and output on all tested architectures.
* Rework tls_check_subject_altname() error handlingtb2023-06-011-12/+13
| | | | | | | Default to having rv = -1 and explicitly goto done to set rv = 0. This matches other code better. ok jsing
* Check for X509_get_ext_d2i() failuretb2023-06-011-4/+10
| | | | | | | | | | X509_get_ext_d2i() (or rather X509V3_get_d2i()) can return NULL for various reasons. If it fails because the extension wasn't found, it sets *crit = -1. In any other case, e.g., the cert is bad or we ran out of memory in X509V3_EXT_d2i(), crit is set to something else, so we should actually error. ok jsing
* Avoid a potentially overflowing checktb2023-06-011-2/+2
| | | | | | | | | | | | This doesn't actually overflow, but still is poor style. Speaking of which: this is now the second time I get to fix something reported by Nicky Mouha by way of a blog post. The first time was the actual SHA-3 buffer overflow in Python where it is not entirely clear who screwed up and how. Hopefully next time proper communication will happen and work. ok jsing
* fix some nits on previousop2023-05-301-6/+10
| | | | | | | | | | - move a sentence out of a Bd block - add some .Pp for spacing - avoid a double colon on a sentence and the usage of second person - mark STORE_CTX with .Vt - change one Vt -> Dv (done after this has been ok'd by beck) ok beck@
* Correct test that was pasto'ed incorrectlybeck2023-05-291-3/+7
| | | | This now tests what the comment says it does
* Correctly catch all return values from X509_NAME_get_index_by_NIDbeck2023-05-291-6/+11
| | | | | | And some comment requests, from jsing@ ok jsing@
* Oops, Fa -> .Fabeck2023-05-291-2/+2
|
* Make X509_NAME_get_text_by[NID|OBJ] safer.beck2023-05-293-22/+125
| | | | | | | | | | | | | | | | This is an un-revert with nits of the previously landed change to do this which broke libtls. libtls has now been changed to not use this function. This change ensures that if something is returned it is "text" (UTF-8) and a C string not containing a NUL byte. Historically callers to this function assume the result is text and a C string however the OpenSSL version simply hands them the bytes from an ASN1_STRING and expects them to know bad things can happen which they almost universally do not check for. Partly inspired by goings on in boringssl. ok jsing@ tb@
* Stop suggesting that children play with loaded revolvers.beck2023-05-291-31/+49
| | | | | | | | | | This takes much of the language that boring uses to document the verify callback, and corrects the historical horror that OpenSSL introduced years ago by suggesting people ignore expiry dates using the callback instead of the verify flags. nits by jsg@ and tb@ ok tb@
* Provide optimised bn_mulw_{addw,addw_addw,addtw}() for aarch64.jsing2023-05-281-1/+68
| | | | | This results in bn_mul_comba4() and bn_mul_comba8() requiring ~30% less instructions than they did previously.
* Provide optimised bn_addw_addw()/bn_subw_subw() for aarch64.jsing2023-05-281-1/+43
|
* Sprinkle some style(9).jsing2023-05-281-15/+15
|
* Expand occurrences of HASH_CTX that were previously missed.jsing2023-05-281-4/+5
| | | | No change in generated assembly.
* Reorder functions.jsing2023-05-281-214/+214
| | | | No intended functional change.
* Clean up includes.jsing2023-05-281-6/+5
|
* Remove now unnecessary do {} while(0);jsing2023-05-281-3/+1
|
* Inline HASH_MAKE_STRING for SHA256.jsing2023-05-281-34/+37
| | | | No change to generated assembly.
* Rewrite BN_{asc,dec,hex}2bn() using CBS.jsing2023-05-281-123/+224
| | | | | | | | | | | This gives us more readable and safer code. There are two intentional changes to behaviour - firstly, all three functions zero any BN that was passed in, prior to doing any further processing. This means that a passed BN is always in a known state, regardless of what happens later. Secondly, BN_asc2bn() now fails on NULL input, rather than crashing. This brings its behaviour inline with BN_dec2bn() and BN_hex2bn(). ok tb@
* correct comment, spotted by tb@beck2023-05-281-4/+4
|
* Refactor tls_check_common_name to use lower level API.beck2023-05-282-14/+51
| | | | | | | | | | | | | | | | | | | | X509_NAME_get_text_by_NID is kind of a bad interface that we wish to make safer, and does not give us the visibility we really want here to detect hostile things. Instead call the lower level functions to do some better checking that should be done by X509_NAME_get_text_by_NID, but is not in the OpenSSL version. Specifically we will treat the input as hostile and fail if: 1) The certificate contains more than one CN in the subject. 2) The CN does not decode as UTF-8 3) The CN is of invalid length (must be between 1 and 64 bytes) 4) The CN contains a 0 byte 4) matches the existing logic, 1 and 2, and 3 are new checks. ok tb@
* Merge X509_VERIFY_PARAM_ID into X509_VERIFY_PARAMtb2023-05-284-110/+73
| | | | | | | | | | Back in the day when essentially every struct was open to all applications, X509_VERIFY_PARAM_ID provided a modicum of opacity. This indirection is now no longer needed with X509_VERIFY_PARAM being opaque itself, so stop using X509_VERIFY_PARAM_ID and merge it into X509_VERIFY_PARAM. This is a first small step towards cleaning up the X509_VERIFY_PARAM mess. ok jsing
* Implement SHA256_{Update,Transform,Final}() directly in sha256.c.jsing2023-05-271-4/+103
| | | | | | | | | | m32_common.h is a typical OpenSSL macro horror show - copy the update, transform and final functions from md32_common.h, manually expanding the macros for SHA256. This will allow for further clean up to occur. No change in generated assembly. ok beck@ tb@
* Add HASH_NO_UPDATE and HASH_NO_TRANSFORM to md32_common.hjsing2023-05-271-5/+7
| | | | | | | This makes it possible to still use minimal parts of md32_common.h, while disabling the update and transform functions. ok beck@ tb@
* Add coverage for calling BN_{dec,hex}2bn() with NULL inputs.jsing2023-05-271-9/+37
|
* Bump LibreSSL versionlibressl-v3.8.0tb2023-05-271-3/+3
|
* Clean up alignment handling for SHA-512.jsing2023-05-272-80/+96
| | | | | | | | | | | This recommits r1.37 of sha512.c, however uses uint8_t * instead of void * for the crypto_load_* functions and primarily uses const uint8_t * to track input, only casting to const SHA_LONG64 * once we know that it is suitably aligned. This prevents the compiler from implying alignment based on type. Tested by tb@ and deraadt@ on platforms with gcc and strict alignment. ok tb@
* Remove malloc interposition, a workaround that was once needed for emacsotto2023-05-271-7/+7
| | | | ok guenther@
* Move verified_chain from SSL to SSL_HANDSHAKEtb2023-05-264-14/+17
| | | | | | | | This is a better version of the fix for the missing pointer invalidation but a bit larger, so errata got the minimal fix. tested by jcs ok jsing
* Forcibly update the EVP_PKEY's internal keyop2023-05-251-13/+25
| | | | | | | | | | | | | | | | | | | | | | | | To aid privilege separation, libtls maintains application-specific data on the key inside the EVP_PKEY abstraction because the EVP API doesn't provide a way to do that on the EVP_PKEY itself. OpenSSL 3 changed behavior of EVP_PKEY_get1_RSA() and related functions. These now return a struct from some cache. Thus, modifying the RSA will no longer modify the EVP_PKEY like it did previously, which was clearly implied to be the case in the older documentation. This is a subtle breaking change that affects several applications. While this is documented, no real solution is provided. The transition plan from one OpenSSL major version to the next one tends to involve many #ifdef in the ecosystem, and the only suggestion provided by the new documentation is to switch to a completely unrelated, new API. Instead, forcibly reset the internal key on EVP_PKEY after modification, this way the change is picked up also by OpenSSL 3. Fixes issue 1171 in OpenSMTPD-portable ok tb@, jsing@
* Update X509_VERIFY_PARAM_inherit() to reflect the change of behaviortb2023-05-241-9/+6
| | | | in x509_vpm.c r1.39.
* Copy the verify param hostflags independently of the host listtb2023-05-242-6/+5
| | | | | | | | | | | | | | | | Without this, hostflags set on the SSL_CTX would not propagate to newly created SSL. This is surprising behavior that was changed in OpenSSL 1.1 by Christian Heimes after the issue was flagged by Quentin Pradet: https://bugs.python.org/issue43522 This is a version of the fix that landed in OpenSSL. There used to be a workaround in place in urllib3, but that was removed at some point. We haven't fixed this earlier since it wasn't reported. It only showed up after recent fallout of extraordinarily strict library checking in urllib3 coming from their own interpretation of the implications of PEP 644. ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-25 00:23:16 +0000