chore: sync latest cloudflare boring updates - #192
Merged
Conversation
…lidation algorithms
Newer Homebrew refuses to load formulae from untrusted third-party taps, which broke the macOS-to-Linux cross-build job.
non-specialized to_string gets an assertion forbidding use of fmt::Error
Building boring-sys for `aarch64-apple-tvos` / `aarch64-apple-tvos-sim` currently fails. `target_os = "tvos"` is unhandled at five places in the build script, and the failures are silent rather than loud: - `should_use_cmake_cross_compilation` falls through to `_ => true`, so a macOS -> tvOS build takes the generic cross-compilation path instead of the Xcode path added in #187. - `CMAKE_PARAMS_APPLE` has no tvOS triples, so `cmake_params_apple` returns `&[]`. - The `target_os` match in `get_boringssl_cmake_config` has no `tvos` arm and ends in `_ => {}`, so with the empty params above no `CMAKE_OSX_SYSROOT` is ever set and CMake builds BoringSSL for the host macOS instead of the tvOS SDK. - `get_extra_clang_args_for_bindgen` has no `tvos` arm, so bindgen reads host macOS headers instead of the tvOS SDK sysroot. - `get_cpp_runtime_lib` misses `tvos`, which then matches `_ if config.unix` and links `stdc++` rather than `c++`. Add tvOS to each. `CMAKE_MACOSX_BUNDLE=OFF` matches the existing iOS entries and is required -- with the default `ON`, CMake's install step for BoringSSL's `bssl` host tool fails. No bitcode cflag for tvOS: bitcode was deprecated in Xcode 14 and the tvOS SDK never wants it, so the new arm is a plain `cmake_params_apple` loop like the `macos` one rather than being folded into the `ios` arm. `x86_64-apple-tvos` is included in the table for completeness even though it is a tier 3 target that needs `-Z build-std`; the mapping costs nothing and is what such a build would need. `arm64e-apple-tvos` is omitted, matching the table's existing treatment of arm64e. Cover both tvOS targets in the `test` job matrix alongside the existing iOS entries. That job builds with `--tests`, so the linker runs and verifies the cross-compilation -- which is what catches the `stdc++` / `c++` mistake above. `x86_64-apple-tvos` is left out because `rustup target add` has no prebuilt std for it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…e default BoringSSL starting with BORINGSSL_API_VERSION 19 (see include/openssl/base.h) changed SSL_CONFIG::enforce_rsa_key_usage to default to true, making client-side RSA leaf keyUsage mismatches a fatal handshake error (KEY_USAGE_BIT_INCORRECT). Many real-world origins serve certificates whose keyUsage does not include the bit required by the negotiated cipher suite; OpenSSL and prior BoringSSL pins accepted them. This adds a new `relax-cert-validation` Cargo feature that applies a build-time patch restoring the historical default (false). When the feature is not enabled, the strict BoringSSL behaviour is preserved. Non-RSA keyUsage enforcement is unaffected in either case. A unit test verifies that a TLS 1.2 ECDHE-RSA server certificate with keyUsage missing the digitalSignature bit is rejected by default and accepted when the feature is enabled.
Change all seal/open methods on AeadCtxRef from &self to &mut self. The TLS-specific AEADs (aes_*_gcm_tls12, aes_*_gcm_tls13) are stateful and internally mutate the EVP_AEAD_CTX during seal operations (nonce counter tracking). Using &self allows LLVM to optimize under the assumption that the context is read-only, which can corrupt nonce state and cause cryptographic failures. This was the root cause of cloudflare/quiche#2383. Using &mut self universally (for both generic and TLS AEADs) is the simplest fix and prevents this class of bug entirely. Also adds Algorithm constructors for the four TLS GCM variants: - aes_128_gcm_tls12 / aes_256_gcm_tls12 - aes_128_gcm_tls13 / aes_256_gcm_tls13 These enforce strictly monotonic nonces at the AEAD level, matching the TLS 1.2 and TLS 1.3 nonce construction requirements. Tests cover: - Round-trip seal/open for all TLS variants - TLS nonce monotonicity enforcement (reuse and backwards rejected) - Contrast: generic GCM accepts non-monotonic nonces
Renew the committed CA and leaf certificates used by the TLS test suite after their August 2026 expiration. Deploy risk: test fixtures only; runtime certificates and package behavior are unchanged.
Keep certificate fingerprints, validity assertions, signatures, and bundled certificate expectations aligned with the renewed test fixtures. Deploy risk: test expectations only; runtime behavior is unchanged.
Merge upstream changes through dbdeb8b while preserving the newer project BoringSSL baseline and adapting certificate validation compatibility.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.
No description provided.