commit | 046fc130d1cd8c78365e00f4781f4c94eb159188 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Sun Aug 01 15:20:53 2021 -0400 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Aug 04 00:02:20 2021 +0000 |
tree | bfa6e142fddf0133279cddf0b3b1a4dbbf2031e9 | |
parent | 116d9250a996c6627bda53b7f1e4cba503785b86 [diff] |
Remove ASN1_STRING_FLAG_MSTRING. This flag is set when an ASN1_STRING is created from a codepath that is aware it is an "mstring" (CHOICE of multiple string or string-like types). With setters like X509_set_notBefore, it is very easy to accidentally lose the flag on some field that normally has it. The only place the flag is checked is X509_time_adj_ex. X509_time_adj_ex usually transparently picks UTCTime vs GeneralizedTime, as in the X.509 CHOICE type. But if writing to an existing object AND if the object lacks the flag, it will lock to whichever type the object was previously. It is likely any caller hitting this codepath is doing so unintentionally and has a latent bug that won't trip until 2050. In fact, one of the ways callers might accidentally lose the ASN1_STRING_FLAG_MSTRING flag is by using X509_time_adj_ex! X509_time_adj_ex(NULL) does not use an mstring-aware constructor. This CL avoids needing such a notion in the first place. Looking through callers, the one place that wants the old behavior is a call site within OpenSSL, to set the producedAt field in OCSP. That field is a GeneralizedTime, rather than a UTCTime/GeneralizedTime CHOICE. We dropped that code, but I'm making a note of it to remember when filing upstream. Update-Note: ASN1_STRING_FLAG_MSTRING is no longer defined and X509_time_adj_ex now behaves more predictably. Callers that actually wanted to lock to a specific type should call ASN1_UTCTIME_adj or ASN1_GENERALIZEDTIME_adj instead. Change-Id: Ib9e1c9dbd0c694e1e69f938da3992d1ffc9bd060 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48668 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@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:
There are other files in this directory which might be helpful: