| commit | 71147d3763466094df692df97afef42e4ce26a4f | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu Aug 14 15:25:30 2025 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Aug 14 13:14:14 2025 -0700 |
| tree | 4f85d8ee52549747bcd0fc4101f6344bdf45de80 | |
| parent | 41478ebb2fde8bdaad1a5554a4391c0834abfc07 [diff] |
Deprecate EVP_PKEY_set_type This function is practically useless. It makes a typed but empty key, which is somehow distinct from an untyped and empty key. Looking for callers within our tests and externally, the patterns are: - EVP_PKEY_set_type(EVP_PKEY_X25519) followed by EVP_PKEY_set1_tls_encodedpoint. This is regrettably needed for that API to work, but we've also marked EVP_PKEY_set1_tls_encodedpoint as deprecated, I think because of this weird half-empty state. Sadly this means we can never totally remove this, and we're stuck with some of these half-empty states. - EVP_PKEY_set_type(EVP_PKEY_NONE). This is used in some tests by callers who try to test their "unknown type" codepaths. The usual pattern is they load a key and then set the type to EVP_PKEY_NONE. The result of this is an empty EVP_PKEY, identical to just calling EVP_PKEY_new. Loading the key was never useful. It's also an error! The function fails because EVP_PKEY_NONE is not a supported type. Callers were relying on a quirk that we clear the key before noticing the parameters are wrong. Write a test and update the comment so we don't forget this behavior is depended on. (Though I'm going to try to fix everyone relying on this.) - EVP_PKEY_set_type(EVP_PKEY_RSA), etc. This does not produce a valid key. It's done in some test code to avoid loading a real key. Our own tests do this too, though it's also to test that EVP_PKEY_missing_parameters works for this weird empty state, that ideally wouldn't be possible in the first place. The immediate motivation is that the work to make EVP more static-linker-friendly collides a bit with EVP_PKEY_set_type(EVP_PKEY_EC). If we're trying to treat P-256 and P-384 as distinct EVP_PKEY types, it's unclear how that operation is supposed to work. Bug: 42290409 Change-Id: Id4368e049abea698f0eaed1419cb366a5fe3a424 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81269 Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Lily Chen <chlily@google.com> Commit-Queue: Lily Chen <chlily@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: