| commit | cc4333d757f765ca81c8f1df125a66711a623219 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Feb 21 00:14:30 2022 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Mar 07 23:10:04 2022 +0000 |
| tree | 38428ab94840ac5fa4bff54a6abe0eebb2d7b44d | |
| parent | e4b3e6afb63fd82e4157733723a9e7a450ae96cb [diff] |
Use X509V3_add_value_int in i2v_AUTHORITY_KEYID. Although the preceding CL fixes x509v3_bytes_to_hex to work with the empty string, it's not really a good representation for zero. Zero as an ASN1_INTEGER is sometimes the empty string (default-constructed) and sometimes a single zero byte (parsed). bytes_to_hex also doesn't capture the sign bit. Instead, use X509V3_add_value_int, matching most of the other i2v, etc., functions in crypto/x509v3. X509V3_add_value_int calls i2s_ASN1_INTEGER, which prints small values in decimal and large values in hexadecimal with a 0x prefix. It is unclear to me whether i2v and v2i are generally expected to be inverses. i2v (or i2s or i2r) is used when printing an extension, while v2i is used when using the stringly-typed config file APIs. However, i2v_AUTHORITY_KEYID does not consume the "serial" key at all. It computes the serial from the issuer cert. Oddly, there is one ASN1_INTEGER, PROXY_CERT_INFO_EXTENSION.pcPathLengthConstraint, which uses i2a_ASN1_INTEGER instead. That one uses hexadecimal without the "0x" prefix, and with newlines. Interestingly, its r2i function is not the reverse of i2r and parses the s2i_ASN1_INTEGER format. Between those, I'm assuming they're not necessarily invertible. Change-Id: I6d813d1a93c5cd94a2bd06b22bcf1b80bc9d937b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51628 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:
There are other files in this directory which might be helpful: