Bump to v4.15.0 from upstream #33
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…oring::v1::HttpsConnector` Closes cloudflare#295. Signed-off-by: Paul Mabileau <[email protected]>
Closes cloudflare#294. Requires breaking changes. The default v0 is changed in favor of v1, but v0 is still kept available, just in a forced module path. It enables dependency de-duplication when consuming it. Signed-off-by: Paul Mabileau <[email protected]>
As of https://boringssl-review.googlesource.com/c/boringssl/+/66288, libssl allows a C++ runtime dependency. As such, we need to link with a cpp runtime library. Implementation is inspired heavily from google/boringssl@54c956b. Before releasing this change, we'll need to figure out a way to support this for windows.
As of https://boringssl-review.googlesource.com/c/boringssl/+/64141, X509_STORE_CTX_cleanup will zero the memory allocated to the X509_STORE_CTX. Because X509StoreContextRef::init invokes X509_STORE_CTX_cleanup once the with_context closure has finished, calling X509StoreContextRef::verify_result (or any API really) is going to be invalid because memory has been zerod out. This is a pretty big footgun, so maybe we should consider screaming a bit louder for this case.
Mid-handshake errors that occur before certificate verification currently look like this: ``` TLS handshake failed: cert verification failed - Invalid certificate verification context [WRONG_VERSION_NUMBER] ``` Despite no certificate even being received yet, the error complains about a failed verification. The cause here is that `cert verification failed` is only omitted if the verification result is `OK`. The default in BoringSSL before verification runs is `INVALID_CALL`, however. `INVALID_CALL` is set/returned in these places: - https://github.com/google/boringssl/blob/44b3df6f03d85c901767250329c571db405122d5/src/ssl/internal.h#L3904 - https://github.com/google/boringssl/blob/44b3df6f03d85c901767250329c571db405122d5/src/ssl/ssl_session.cc#L396 - https://github.com/google/boringssl/blob/44b3df6f03d85c901767250329c571db405122d5/src/ssl/ssl_x509.cc#L713 It is not used anywhere else as a verification result code. To improve the error message, this commit adds `INVALID_CALL` as a verification result for which no additional error is dislayed.
X25519MLKEM768 is the standardised successor of the preliminary X25519Kyber768Draft00. Latest browsers have switched to X25519MLKEM768. Cloudflare supports both on the edge. We've had support for X25519MLKEM768 in this crate for a while, but didn't enable by default. We're now enabling serverside support by default. We also let clients advertise support when set to kx-client-pq-supported. We don't enable support by default yet for clients set to kx-client-pq-preferred, as that would cause an extra round-trip due to HelloRetryRequest if the server doesn't support X25519MLKEM768 yet. BoringSSL against which we build must support X25519MLKEM768, otherwise this will fail.
We can drop the once_cell dependency since the same functionality is implemented in std now. Requires bumping MSRV to 1.80.
We don't need the workaround that was initially introduced for a bug in openssl, and OPENSSL_init_ssl always calls into CRYPTO_library_init on boringssl, so just call it explicitly.
build: Fix the build for 32-bit Linux platform
cmake-rs' jobserver doesn't work reliably, if at all. One workaround is to set CMAKE_BUILD_PARALLEL_LEVEL to available_parallelism(). On my machine it shaves ~35 seconds off of boring-sys builds.
We currently expose this method on `SslContextBuilder`, which is fine for bootstrapping an `SSL_CTX`, but subsequent attempts to set ECH keys (like during key rotation) can only happen via `SslContextRef`. Also update the method on the builder to take an immutable reference to self because the API is thread safe.
There's a bug on OSX that prevents the CMake jobserver from working properly, and so CMake defaults to a single-threaded build. It's not clear when this is actually going to get fixed, so recent versions of cmake-rs just disable the jobserver and have CMake fall back to the number of available cores: rust-lang/cmake-rs#229 This means we don't need e6833b0
…port" This reverts commit 49d5a61.
…`hyper_boring::v1::HttpsConnector`" This reverts commit e518c24.
… reference (cloudflare#320) Previously, set_ech_keys would consume the SslEchKeys struct to enforce the requirement that the struct is immutable after initializing it on a SSL_CTX. The problem with this is that it requires applications to needlessly reallocate the SslEchKeys struct if they want to initialize keys on multiple SSL_CTXs, which is a pretty common pattern. To work around this, we introduce a builder (SslEchKeysBuilder) that requires mutable access to add keys to the underlying struct. set_ech_keys takes in a reference to SslEchKeys, which can only be made via consuming the builder.
Some users of boring have issues with newer versions of cmake. Because we have an alternative solution, we can hold off on the bump for now.
See sfackler/rust-openssl#2360 and https://nvd.nist.gov/vuln/detail/CVE-2025-24898. From the rust-openssl PR: `SSL_select_next_proto` can return a pointer into either the client or server buffers, but the type signature of the function previously only bound the output buffer to the client buffer. This can result in a UAF in situations where the server slice does not point to a long-lived allocation. Thanks to Matt Mastracci for reporting this issue.
v4.15.0 was tagged a few days ago but wasn't released until today, where a new commit made it to master and snuck into the publish. I updated the v4.15.0 tag to point to the right commit hash as well.
andrew-signal
force-pushed
the
signal/v4.15.0
branch
from
58ed4a7 to
ea8082f
Compare
andrew-signal
force-pushed
the
signal/v4.15.0
branch
from
ea8082f to
1014d31
Compare
|
Upstream has taken the CI fix, so I merged in upstream master, which is v4.15.0 + the CI fix. |
|
Worth updating the PR title to make it easier to find later, then, but yeah, clean merge is a good merge. |
jrose-signal
approved these changes
Mar 10, 2025
andrew-signal
changed the title
|
Merged manually into main to preserve history for future upstream updates. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was no manual merge conflict resolution for this change; I was just able to merge in upstream directly.
I tested via running cargo test locally on both Rust stable and Rust 1.80 (the new MSRV for cloudflare/boring). I also tested that the libsignal tests pass while building with this new version of the dependency.