Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upstream merge 2024-03-21 #1506

Merged
merged 9 commits into from
Apr 8, 2024
Merged

Conversation

justsmth
Copy link
Contributor

@justsmth justsmth commented Mar 21, 2024

Description of changes:

Merging from Upstream considering commits from google/boringssl@aa533e0 (Nov 20, 2023) to google/boringssl@d9b81bb (Nov 27, 2023).

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.

@codecov-commenter
Copy link

codecov-commenter commented Apr 1, 2024

Codecov Report

Attention: Patch coverage is 87.50000% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 77.25%. Comparing base (1e4601e) to head (d54a7bc).
Report is 25 commits behind head on main.

Files Patch % Lines
crypto/x509/x509_lu.c 72.22% 5 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1506      +/-   ##
==========================================
+ Coverage   77.01%   77.25%   +0.23%     
==========================================
  Files         426      425       -1     
  Lines       71738    71399     -339     
==========================================
- Hits        55252    55156      -96     
+ Misses      16486    16243     -243     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@justsmth justsmth changed the title [DRAFT] Upstream merge 2024-03-21 Upstream merge 2024-03-21 Apr 3, 2024
@justsmth justsmth marked this pull request as ready for review April 3, 2024 12:05
@justsmth justsmth requested a review from a team as a code owner April 3, 2024 12:05
Bug: 426
Change-Id: I29d4e1d5a5c319ba7bedab197efaf0427a8115af
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63943
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 4e400359bcffad4cd6fe4d7db5c83c1eb085cd34)
Bug: 426
Change-Id: Ie96fd593817cbbfc11f78bb5608fcc9eb0b8d773
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63944
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
(cherry picked from commit 2a63b90f103ab601cb81e347c0f0ad767e40e019)
Warts and all.

Bug: 426
Change-Id: I45c7ae59b65055b560df6019a98269b3a28fd24f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63945
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit a697bcb71dc1b822e681fc3defb61786f6c26c2e)
These probably shouldn't be public API, but ah well.

Bug: 426
Change-Id: I4c5a81c70d3b2d5866ef494ac2a6710a662103c8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/63947
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 5bef6ec18376dc684d0cf336ee7d455afdc2c395)
X509_INFO only exists to be a return value to PEM_X509_INFO_read. There
is no use in letting callers create these objects, since they cannot do
anything with it. Only X509_INFO_free is needed.

Also cut a ton of unused fields from X509_PKEY.

Change-Id: I322589f04883903e1fe5c23c3966ecf631e85b7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64127
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

(cherry picked from commit fcd464ce97d96fd0278ad3082a8429022ae2c4d7)
This was never used externally. It's a remnant of when we supported
stack-allocated X509_STOREs, but now its opaque.

Change-Id: Idb997237ca81f4c35795cfc8c9d2ee222629e1ce
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64128
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

(cherry picked from commit 698aa894c96412d4df20e2bb031d9eb9c9d5919a)
… context

This wasn't possible when X509_STORE_CTX was stack-allocated because
X509_STORE_CTX_init needed to account for an uninitialized struct. But
now it is always initialized, so we can avoid this footgun. This also
matches what OpenSSL does nowadays.

Change-Id: I266be58204b8cd374fa4896c1c66a35ffaa762ea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64141
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit 1685bd140f6eeb6939c73756be70c888dde32c5e)
This is a bit of a mess. The immediate motivation here is that there is
no legitimate reason to ever call X509_OBJECT_free_contents outside of
the library. Unsurprisingly, this means rust-openssl uses it.

rust-openssl uses it because they want to be able to free X509_OBJECTs.
Add OpenSSL 1.1.x's X509_OBJECT_free, which is what they should be using
it instead. As it turns out, they don't *actually* need to free
X509_OBJECTs. This is just some design mistake that cause them to need
free functions for types they never free. On top of that, the only
reason rust-openssl references X509_OBJECT is for
X509_STORE_get0_objects, but their use of that API is a Rust safety
violation anyway. It's all a mess.

As for whether freeing it ever makes sense, the question is whether
X509_STORE_get_by_subject needs to be a public API. In so far as it is
public, callers would need to create empty X509_OBJECTs as an output,
now that X509_OBJECT is opaque. There are also other users of
X509_STORE_get0_objects that might benefit from an
X509_STORE_get1_objects, in which case X509_OBJECT_free will be useful.

For now just to unblock fixing the more immediate rust-openssl mistake
(rather than the underlying mistake), add the APIs that
X509_STORE_get_by_subject callers would need if they existed.

There's quite a bit to clean up around X509_OBJECT, but start by adding
these APIs.

As part of this, since rust-openssl prevents us from removing
X509_OBJECT_free_contents, deprecate it and fix it to leave the
X509_OBJECT in a self-consistent state. (This is moot because
rust-openssl will never call it, but still.)

Change-Id: I78708f2d2464eb9a18844fef0d62cb0a727b9f47
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64129
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

(cherry picked from commit c2b7df5850398dc7c73146c07f6eed95dd363a48)
Some things of note:

- Anyone calling X509_OBJECT_up_ref_count is breaking X509_OBJECT's
  internal invariants, or relying on someone else handing back an
  X509_OBJECT with broken invariants.

- X509_LOOKUP_by_subject hands back an X509_OBJECT with broken internal
  invariants. Fortunately, it is never called, so unexport it as a the
  first step to cleaning this up.

Change-Id: Ia67693f802671cf857bf51aec6e20f27d1525212
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64130
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
(cherry picked from commit d9b81bb43a24b3adb6e8a616a4828e1bad89c486)
@justsmth justsmth merged commit d4f233c into aws:main Apr 8, 2024
45 checks passed
@justsmth justsmth deleted the upstream-merge-2024-03-21 branch April 8, 2024 19:56
andrewhop added a commit that referenced this pull request Apr 29, 2024
…1560)

### Issues:
Resolves #1556

### Description of changes: 
Remove the duplicate X509_OBJECT_new and X509_OBJECT_free declarations
from #1506.

### Testing:
I'm still looking into why our CI didn't catch this and what we can add
that would catch this in the future.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants