commit | 56383dabf472100181226cd14249f04c69a0c10b | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Fri Mar 29 12:42:50 2024 -0400 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Mar 20 03:41:54 2025 -0700 |
tree | 133d2f252cea9c114f58b99e32c3235d34d95ab9 | |
parent | 9ba6410319a4e80c81a0f9423f68385d81735675 [diff] |
Simplfy fuzzer build Instead of having a pair of bespoke build definitions use the standard FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION toggle. We actually originated the idea of a fuzzing-specific build toggle, and then libFuzzer standardized a toggle when we talked to them about what we were doing. The problem is our fuzzer mode toggle substantially changed the TLS stack behavior, such that downstream code would likely go haywire. So we couldn't easily fold into the standard one, and all of BoringSSL's downstream fuzzer builds were messy. Instead, make a few changes: 1. Switch BORINGSSL_UNSAFE_DETERMINISTIC_MODE to FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION. That flag is not expected to cause downstream issues as it just makes the PRNG deterministic. 2. Replace BORINGSSL_UNSAFE_FUZZER_MODE with a runtime toggle that is only available when building with FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION. 3. Instead of the no_fuzzer_mode fuzzers being special corpora for the client and server fuzzers, they're now just separate fuzzerrs and follow the usual naming conventions between fuzzers and their corpora. Update-Note: Downstream fuzzer builds can now be simplified. If the fuzzing infrastructure already builds with FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION, the separate boringssl_fuzz (or whatever) target can be removed. Bug: 42290128 Change-Id: Ia1e479777f366908951e15067c96c9767c229f0a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77749 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: