Upstream merge 2024 01 05 #1385
Merged
Conversation
This file contains 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
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1385 +/- ##
==========================================
- Coverage 76.86% 76.85% -0.02%
==========================================
Files 424 425 +1
Lines 71339 71337 -2
==========================================
- Hits 54837 54823 -14
- Misses 16502 16514 +12 ☔ View full report in Codecov by Sentry. |
andrewhop
previously approved these changes
Jan 10, 2024
justsmth
force-pushed
the
upstream-merge-2024-01-05
branch
from
6f572f0 to
790e6d0
Compare
justsmth
force-pushed
the
upstream-merge-2024-01-05
branch
from
790e6d0 to
b74bdf4
Compare
nebeid
previously approved these changes
Jan 11, 2024
andrewhop
previously approved these changes
Jan 11, 2024
justsmth
force-pushed
the
upstream-merge-2024-01-05
branch
from
b74bdf4 to
616188b
Compare
nebeid
approved these changes
Jan 12, 2024
This CL adds the Shipped field (and may update the License File field) in Chromium READMEs. Changes were automatically created, so if you disagree with any of them (e.g. a package is used only for testing purposes and is not shipped), comment the suggested change and why. See the LSC doc at go/lsc-chrome-metadata. Bug: b:285450740 Change-Id: I63755d8a42ea69ff6d3a4e0c21ddacd2b7ce9053 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61545 Auto-Submit: Anne Redulla <[email protected]> Reviewed-by: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]> (cherry picked from commit 1f786137e4045b88d26035306ef826ff4a30befd)
glibc and musl do not make getentropy available from <unistd.h> unless _BSD_SOURCE (or _GNU_SOURCE) is defined. _BSD_SOURCE, in glibc, triggers a deprecation warning to use _DEFAULT_SOURCE instead. It seems _DEFAULT_SOURCE might be fairly broadly defined, but some Emscripten-based toolchain (which uses musl) didn't end up defining it for some reason. Just do it explicitly in the source file so it always works. Change-Id: I4532d4adb9f8ed55c43763ca2dd426b5fa1b4f5c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61625 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]> Auto-Submit: David Benjamin <[email protected]> (cherry picked from commit 2a900c16a4110e9304e4a2face2d287ac6c7975a)
We'd leak the socket if Connect failed in the middle. (This doesn't especially matter. The test process would just exit anyway.) Change-Id: I8e1f252781810b1d8ef3c41bd707dfebb0371e60 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61665 Reviewed-by: Bob Beck <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]> (cherry picked from commit a4f8755f8e66b77ca2230f376bc5d5d54b28544e)
Our BIO_snprintf is just a thin wrapper over the libc one, and we already call it directly in other places. Just call the libc one consistently. Change-Id: Ia7daf26b9789ddcecab67118c4ec4a077aad5a22 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61685 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: Bob Beck <[email protected]> Auto-Submit: David Benjamin <[email protected]> (cherry picked from commit 23d6e4cce97a9b66a53fb4286341fd02d2b99e40)
One less thing to update when we next bump the minimum. Bug: 607 Change-Id: I50bd01b14499a7ed7904a5e111c3e1df57eaa144 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61645 Reviewed-by: Bob Beck <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: David Benjamin <[email protected]> (cherry picked from commit bc80d929f87dc03bf4106f466b7d88b45d52e02f)
https://boringssl-review.googlesource.com/c/boringssl/+/61685 had the side effect of unobscuring some snprintf calls to GCC. There are a couple instances that cannot truncate, but GCC doesn't know this because it doesn't know the bounds on struct tm. Fortunately, -Wformat-truncation, at level 1, is satisfied by checking the return value, so do that. Change-Id: Iad3ae0d51a951c10f1b706be7f6e127f0b9e6dee Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61705 Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]> Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]> (cherry picked from commit 39eee12d0da9e5e1bff77fd82309f8e7d670d9a6)
This corresponds to the libcrypto_baremetal build target in Android,
which is an embedded-style platform that uses a subset of the bionic
libc. It will also, eventually, use getentropy for its PRNG.
As part of this, generalize the OPENSSL_TRUSTY exclusion for file BIOs
to OPENSSL_NO_FILESYSTEM. Upstream OpenSSL uses OPENSSL_NO_STDIO, but
that excludes all of FILE entirely. We already require FILE in quite a
few places (urandom.c, self_test.c) for writing to stderr, and FILE is
part of C standard library. So, let's tentatively say that we require
you have FILE and stderr.
Instead, OPENSSL_NO_FILESYSTEM is saying you don't have fopen. You're
still required to have the three std{in,out,err} FILEs, and given a
FILE, you need to allow the standard operations on it. (Possibly in
forms that always fail.)
To keep us honest, whenever a function is excluded, I've dropped it from
the header too, and followed callers up the chain. I have not attempted
to make the tests work when these are excluded. Later CLs in this series
will do the same for NO_SOCK and NO_POSIX_IO. This was a little tedious,
but not too bad.
(I assume we'll end up changing our minds on this a lot. For now, let's
try this.)
I haven't yet restored OPENSSL_RAND_TRUSTY or removed the OPENSSL_TRUSTY
ifdef on file.c. Having a separate CL makes it a bit easier to revert if
something goes wrong.
This depends on
https://android-review.googlesource.com/c/platform/bionic/+/2659335,
which fixes the header bionic uses for getentropy.
Bug: 629, b:291102972
Change-Id: Idd839cd3fa4253128de54bd1be7da261dbcdeb7c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61726
Auto-Submit: David Benjamin <[email protected]>
Reviewed-by: Bob Beck <[email protected]>
Commit-Queue: Bob Beck <[email protected]>
(cherry picked from commit 5ba5db1a29ef54dc3ee2efbc5bdb3d95b77fc928)
These functions are just wrappers over BIO_ctrls, shared between the fd and socket BIOs. Though we don't currently support one, it is conceivable that there would be a platform with socket BIOs but not fd BIOs. In that case, the BIO_get_fd function would still be useful to implement SSL_get_rfd. (And someone could conceivably implement it in another BIO.) Bug: 629 Change-Id: I7ac3561f76af86af32d70b1c6265c4caeaecb129 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61727 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]> (cherry picked from commit 68beac6373aeee787e0919b240c1a8177554cac8)
As part of this, factor out some of the socket bits. I tried to write the sockaddr mess in a way that's strict-aliasing-clean, at least as far as code we own goes. But the API is really not designed for it, and who knows what effective type the underlying libc functions expect. (Fortunately it's mostly syscalls, which definitely escape the abstract machine.) Change-Id: I12621f6c40f074ff7423dd46ddceca120ba63db9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61728 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]> (cherry picked from commit 2b5d6ba0341588e4bbd53d6055118e5472657b49) AWS-LC: Changed OwnedSocket::release to be compatible with C++11.
On Windows, sockets and fds are different, so we need to be a little carefully. The fd functions (which are really a userspace construct inside the libc) report errors by writing to errno: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/read?view=msvc-170 While the socket functions (which are really thin wrappers over Windows HANDLEs) use WSAGetLastError: https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recv https://learn.microsoft.com/en-us/windows/win32/winsock/error-codes-errno-h-errno-and-wsagetlasterror-2 Moreover, the error values are different, so we shouldn't mix them together: https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2 https://learn.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170 Finally, by borrowing OpenSSL's distinct OPENSSL_NO_SOCK and OPENSSL_NO_POSIX_IO options, we arguably should account for all combinations of one or the other being missing. (Ugh.) To account for that, I've moved bio_fd_should_retry into its own file that isn't conditioned on anything. It only depends on <errno.h>, which is part of the C standard library, and used elsewhere already. Change-Id: I0519d7d68c32062e1220ffca0ab57a9cac9f7e5f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61729 Commit-Queue: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]> (cherry picked from commit df13691019be62da728e0c63463fe51bb5d7c29d)
This warning was being tripped because lib_buf and reason_buf made GCC, incorrectly, believe that the strings could get that long, and then attempted to sum up the snprintf to 120, obtained by inlining some things. Those buffers were larger than they needed to be, so bringing it down is sufficient to silence things. That said, the buffer bounds are supplied by the caller and it is expected that truncation can occur, so the warning is just incorrect. The warning can also be silenced by checking the snprintf return value. As we're already trying to detect truncation, we may as well do it with the return value and skip the extra strlen call. Either of the two changes is sufficient to suppress the warning, but both seem worthwhile, so I've done them both. Change-Id: Ia1b1de67bba55da6f0d07e3682165a1820ce2c9e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61805 Auto-Submit: David Benjamin <[email protected]> Reviewed-by: Bob Beck <[email protected]> Commit-Queue: Bob Beck <[email protected]> (cherry picked from commit 6bd1e1504670dc96a76eb9858da4117bba586a41)
justsmth
force-pushed
the
upstream-merge-2024-01-05
branch
from
616188b to
974956e
Compare
andrewhop
approved these changes
Jan 12, 2024
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.
Description of changes:
Merging from Upstream considering commits from google/boringssl@1f78613 to google/boringssl@6bd1e15
Call-outs:
See internal document as well as "AWS-LC" notes inserted in some of the commit messages for additions/deviations from the upstream commit.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.