Pull in latest boring #36
Open
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
This algorithm is advertised with "kx-client-pq-supported" but not with "preferred". However the algorithm is wide spread enough that preferring it is not a significant risk.
As of boringSSL commit a430310d6563c0734ddafca7731570dfb683dc19, we no longer need to make exceptions for the types of BufLen, ProtosLen, and ValueLen, which means the "fips-compat" feature is no longer needed for "fips" users. Currently "fips" implies "fips-compat". To allow users to upgrade without breaking API compatibility with boring version 4, add a new feature, "fips-no-compat", that does not imply "fips-compat". In boring 5, we should remove "fips-no-compat" and decouple "fips-compat" from "fips".
Modify the "fips" feature so that it no longer implies "fips-compat". The latter is no longer needed for recent builds of boringSSL; users who need older builds will need to enable "fips-compat" explicitly. Also, remove the "fipps-no-compat" feature, as it's now equivalent to "fips".
Internal users often have two builds for `boring`, one using a precompiled build of boringSSL and another built from source with patches applied. However the features that enable these builds are mutually exclusive. For example, the `"pq-experimental"` feature is required to build the source with all of the necessary codepoints for PQ key exchange, but if this feature is enabled and a precompiled boringSSL is provided, then the build will fail. This means users will have to also control their builds with mutually exclusive features. An alternative is to *ignore* features that enable patches whenever a precompiled boringSSL is provided. This is a little different from the "assume patched" environment variable, which applies whenever we're building from source.
The "fips" feature implies use of a prebuilt boringSSL. The boringSSL API consumed by `SslCurve` in incompatible with older versions of boringSSL. In the `ffi` bindings, the following symbols don't exist in older builds: * NID_X25519MLKEM768 * SSL_CURVE_X25519_MLKEM768 * NID_X25519Kyber768Draft00Old The following symbols have been renamed: * SSL_CURVE_P256KYBER768DRAFT00 => SSL_CURVE_P256_KYBER768_DRAFT00 * SSL_CURVE_X25519KYBER512DRAFT00 => SSL_CURVE_X25519_KYBER512_DRAFT00 * SSL_CURVE_X25519KYBER768DRAFT00OLD => SSL_CURVE_X25519_KYBER768_DRAFT00_OLD * SSL_CURVE_P256KYBER768DRAFT00 => SSL_CURVE_P256_KYBER768_DRAFT00 Meanwhile, the `ssl_set_curves_list()` API is stable across these versions of boringSSL. These codepoints are added to the `SslCurve` API whenever "pq-experimental" is enabled. Since this feature is no longer mutually exclusive with prebuilt boringSSL (`boring-sys` just ignores patches), we also need to disable this API whenever "fips" is enabled.
This was added in cloudflare#264, but not documented so far.
…flare#338) Newer versions of FIPS don't need any special casing in our bindings, unlike the submoduled boringssl-fips. In addition, many users currently use FIPS by precompiling BoringSSL with the proper build tools and passing that in to the bindings. Until we adopt the Update Stream pattern for FIPS, there are two main use cases: 1. Passing an unmodified, precompiled FIPS validated version of boringssl (fips-precompiled) 2. Passing a custom source directory of boringssl meant to be linked with a FIPS validated bcm.o. This is mainly useful if you carry custom patches but still want to use a FIPS validated BoringCrypto. (fips-link-precompiled) This commit introduces the `fips-precompiled` feature and removes the `fips-no-compat` feature.
* boring(x509): impl Clone of X509Store
ubuntu 20.04 is now deprecated: actions/runner-images#11101
This method reliably retrieves the certificate the `X509_STORE_CTX` is verifying, unlike `X509_STORE_CTX_get_current_cert`, which may return the "problematic" cert when verification fails.
…" (cloudflare#353) * Revert "feat(x509): Implement `Clone` for `X509Store` (cloudflare#339)" This reverts commit 49a8d09. See <cloudflare#120>. * Ensure Clone is not added to X509Store * Add comment about why X509Store must not implement Clone --------- Co-authored-by: Kornel <[email protected]>
This method takes ownership of the given verify param.
As X509_STORE_CTX_init may fail after setting some values that should outlive the store context, we must ensure we clean things up on its error path too. We also know it's always ok to call X509_STORE_CTX_cleanupas X509_STORE_CTX_init starts with a call to it.
As X509_STORE_CTX_init requires its arguments to outlive the store context, we take ownership of all of them and put them in the store context's ex data, ensuring the soundness of the operation without the mandatory call to X509_STORE_CTX_cleanup after a closure is run.
This release includes a fix for a build issue with the latest XCode release.
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.
This has the bindgen update that will fix signalapp/libsignal#615