commit | c1af314f524ef4b5989f27d3ac2e0ed993408856 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Mon Apr 07 12:50:26 2025 -0400 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Apr 14 13:42:25 2025 -0700 |
tree | 212ed7880e08d21131bf058ddc633c2d6f6913cb | |
parent | fda22fa7dbe9b841a2605ca78fbd32f2e3cb1a91 [diff] |
Add EVP_marshal_digest_algorithm_no_params See https://boringssl-review.googlesource.com/c/boringssl/+/67088 for a discussion of the long and sordid history here. It seems the default is actually without NULL, but a bunch of use cases (primarily ones we care about) require you to include the NULL due to historical mistakes. We care about encoding digest AlgIds in: - RSASSA-PKCS1-v1_5 DigestInfo: NULL should be included, though we don't use that function here. - RSASSA-PSS and RSAES-OAEP AlgIds: NULL should be included. We don't use that function here, but we may in the future. - PKCS#12: This is ambiguous, but I think the best behavior for now is to continue sending NULL. See comment added to that file. - OCSP: I think this actually should omit the NULL, but we, OpenSSL, and Go all include it, so I've included it for now. - PKCS#7 and (if we implement it) CMS: This should omit the NULL. We currently don't use this function in our PKCS#7 implementation. Although the default probably should be to omit it, we seem to want to include it in almost all our current callers, I've added a no_params variant for the new behavior for now. In the future we can reevaluate this and, if desired: - Add a with_null API - Make the unsuffixed one into the no_params one (backwards-incompatible) - Retire the no_params one Fixed: 42290589 Change-Id: Icc62f9af8cddfbdb5317b3a0b0fb2bf46ff74408 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78449 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@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:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: