Upstream merge 2024-03-21 #1506

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)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upstream merge 2024-03-21 #1506

Upstream merge 2024-03-21 #1506

Commits on Apr 8, 2024