| commit | 0ffd3658dcdc21a6c56d234cf2a6008487dcfaa7 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Jul 23 13:18:31 2023 -0700 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Jul 24 17:02:01 2023 +0000 |
| tree | e91ad0942a47e826d91d8d6d6177868970cfaf22 | |
| parent | e9f816b12b3e68de575d21e2a9b7d76e4e5c58ac [diff] |
Use a stub fopen implementation when OPENSSL_NO_FILESYSTEM is set Detecting errors (i.e. fs-less platforms using fs-only APIs) at compile time is generally preferable to doing so at runtime, so https://boringssl-review.googlesource.com/c/boringssl/+/61726 opted to remove the APIs altogether on applicable targets. However, Trusty uses rust-openssl somewhere and rust-openssl binds a bunch of filesystem-dependent APIs unconditionally. To keep that working, switch to a stub fopen when OPENSSL_NO_FILESYSTEM is set. We effectively model a platform where the filesystem "exists", but is empty. Upstream OpenSSL similarly has OPENSSL_NO_STDIO still define the file BIO (unlike the socket BIO, which is excluded), but in a stub form. As part of this, I've gone ahead and resolved one of the Trusty TODOs. It does produce a duplicate symbol with [1], but things seem to link fine in treehugger. In case it does break, I've bumped BORINGSSL_API_VERSION, so we can go in and condition it if needed. [1] https://android.googlesource.com/trusty/lib/+/refs/heads/main/lib/openssl-stubs/bio.c Bug: 629 Change-Id: I4f20d872a7cde863d21c78090f270b77b03545fa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61925 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: 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:
There are other files in this directory which might be helpful: