Upstream merge 2025 01 02 #2090
Merged
+129
−87
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 ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2090 +/- ##
==========================================
- Coverage 78.92% 78.92% -0.01%
==========================================
Files 610 610
Lines 105137 105147 +10
Branches 14911 14899 -12
==========================================
+ Hits 82983 82989 +6
- Misses 21503 21506 +3
- Partials 651 652 +1 ☔ View full report in Codecov by Sentry. |
nebeid
force-pushed
the
upstream-merge-2025-01-02
branch
3 times, most recently
from
514687e to
a013cd6
Compare
nebeid
force-pushed
the
upstream-merge-2025-01-02
branch
from
a013cd6 to
5063e3f
Compare
nebeid
force-pushed
the
upstream-merge-2025-01-02
branch
2 times, most recently
from
ea87a30 to
27f0837
Compare
We've historically settled on treating asserts as not in scope for our constant-time goals. Production binaries are expected to be optimized builds, with debug assertions turned off. (We have a handful of assertions in perf-sensitive code that you definitely do not want to run with.) Secret data has invariants too, so it is useful to be able to write debug assertions on them. However, combined with our default CMake build being a debug build, this seems to cause some confusion with researchers sometimes. Also, if we ever get language-level constant-time support, we would need to resolve this mismatch anyway. (I assume any language support would put enough into the type system to force us to declassify any intentional branches on secret-by-data-flow bools, notably those we assert on.) So I'm inclined to just make our asserts constant-time. There are two issues around asserts, at least with our valgrind-based validation: The first is that a couple of asserts over secret data compute their condition leakily. We can just fix these. The only such ones I found were in bn_reduce_once and bn_gcd_consttime. The second is that almost every assert over secret data will be flagged as an invalid branch by valgrind. However, presuming the condition itself was computed in constant time, this branch is actually safe. If we were willing to abort the process when false, the assert is clearly publicly true. We just need to declassify the boolean to assert on it. assert(constant_time_declassify_int(expr)) is really long, so I made an internal wrapper macro declassify_assert(expr). Not sure if that's the best name. constant_time_declassify_assert(expr) is kinda long. constant_time_assert(expr) fits with the rest of that namespace, but reads as if we're somehow running an assert without branching, when the whole point is that we *are* branching and need to explicitly say it's okay to. Fixed: 339 Change-Id: Ie33b99bf9a269b11d2c48d246cc4934be7e239ff Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65467 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]> (cherry picked from commit 9b8b483276da2b3d36ea21e97743e310314a8de0)
gen_group wasn't copied over. Change-Id: If5341dce69fe0297b6bd9a5fb7ed34d546201604 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67167 Reviewed-by: Bob Beck <[email protected]> Commit-Queue: David Benjamin <[email protected]> (cherry picked from commit 8248baaf3e14895cc85255c009aace5fb92d0c95)
AWS-LC: - X509_TRUST is in include/openssl/x509.h; the check_trust function pointer was changed there. Change-Id: Ie16e9ab0897305089672720efa4530d43074f692 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67387 Auto-Submit: Theo Buehler <[email protected]> Reviewed-by: Bob Beck <[email protected]> Reviewed-by: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]> (cherry picked from commit 4ac76f07a401b9b11d6ff305049721cfe3f6a777)
Lots of code relies on this, so we ought to document it. A null STACK_OF(T) is treated as an immutable empty list. AWS-LC: - sk_TEST_INT_find takes 2 arguments only due to aws@9860446 - Based on changes to stack.h L-513-515 in the same commit, in compatibility with OpenSSL, -1 is returned in the last check in NullIsEmpty test. Change-Id: I10d0ba8f7b33c7f3febaf92c2cd3da25a0eb0f80 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67407 Reviewed-by: Theo Buehler <[email protected]> Auto-Submit: David Benjamin <[email protected]> Commit-Queue: Bob Beck <[email protected]> Reviewed-by: Bob Beck <[email protected]> (cherry picked from commit 821fe3380cce646fa3557b882d91fba318981b9b)
nebeid
force-pushed
the
upstream-merge-2025-01-02
branch
from
27f0837 to
89a4869
Compare
smittals2
approved these changes
Jan 15, 2025
They are only used in internal functions, so there is no public API that an external customer could be using them from. |
andrewhop
approved these changes
Jan 17, 2025
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 between
google/boringssl@9b8b483 (Mar 20, 2024) and google/boringssl@821fe33 (Mar 22, 2024).
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.