| commit | 608becc67282174594fdaf0ec9c96daca9710d2f | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sat Jan 20 12:10:16 2024 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Jan 31 23:09:40 2024 +0000 |
| tree | 4aa52a455d356139ee9963dc2d25c0084ef19cf8 | |
| parent | 56d3ad9d23bc130aa9404bfdd1957fe81b3ba498 [diff] |
Fix strict aliasing issues with DES_cblock After all, we have to keep this robust, modern cipher conforming to C well-definedness expectations! These functions should have simply taken uint8_t* pointers. Make internal _ex variants that fix this. I've not bothered updating the public APIs because it will cause a ton of downstream churn and make those APIs even more OpenSSL-incompatible. (OpenSSL's APIs take a const-incorrect uint8_t (*in)[8]. Both our struct and their pointers expect callers to call with &foo.) This does not seem worth the trouble. Also since the underlying functions now access as uint8_t*, I suspect this broadly fixes strict aliasing issues with callers that cast from a byte array. (Though perhaps in->bytes should be (const uint8_t*)in?) Ideally c2l and l2c would be replaced with CRYPTO_load_u32_le and CRYPTO_store_u32_le. (It's a little rude for a header to squat those names, especially when those name often vary in endianness.) I did that in a couple places where we'd otherwise increment a pointer declared with the funny array parameter syntax. Otherwise I left it alone for now. Fixed: 683 Change-Id: I7b0d8b2a16697095ebf42a71482c4ba805a193e4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65690 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:
There are other files in this directory which might be helpful: