BN_mod_exp_mont_consttime originally assumed accesses within a cache
line were indistinguishable and indexed into a cache line with secret
values. As a result, it required all of its tables, etc., to be
cache-line-aligned. Nowadays, the standard constant time memory model is
to assume the whole address leaks and not make these assumptions.
In particular, CacheBleed (CVE-2016-0702) showed this assumption was
false and which cache bank you accessed as leaked. OpenSSL's fix for the
assembly (mont5 and rsaz) appears to match the standard constant-time
model. However, its fix to the C code narrowed the assumption to cache
banks, so the alignment was still necessary.
After https://boringssl-review.googlesource.com/c/boringssl/+/33268, we
dropped this and use the standard model. All together, it should mean we
no longer make assumptions about cache lines. Update all the comments
and variable names accordingly.
Change-Id: I7bcb828eb2751a0167c3a3c8242b1b3971efc708
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55227
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I have a use for these in the chrome verifier conversions, we
could choose to make them hidden again after a future move to
boringssl..
Change-Id: If059debbdf482d64577ad04c1ec4f9c82724de1e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55305
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Back in https://boringssl-review.googlesource.com/c/boringssl/+/33268, I
wrote that I had no idea what the mont5 assembly was doing. In
preparation for fixing up some comments around
BN_mod_exp_mont_consttime, I wanted to understand whether we were still
making assumptions about cache lines.
Happily, for the mont5 code, the answer is no, we are not. We just make
a bunch of masks and apply them in the natural way. But we do require
16-byte alignment on the table, because we use movdqa to read out of it.
I didn't look as closely at RSAZ, but I believe it too is fine. It
fairly quickly tosses $power into an XMM register and builds up masks,
rather than incorporating it into address computations.
(Both scatter5 functions incorporate it into the address, but that's
part of table building, where the index is public. I've updated the
comments to note when the index is secret or public.)
There is one reference to cache lines in the comments of mont5.pl, in
computing $N. However, $N has been unused since
https://boringssl-review.googlesource.com/c/boringssl/+/7244. (There are
references to $N[0] and friends, but those refer to @N, which is a
completely unrelated variable.) Remove it.
Change-Id: I1fac0660dffcd1380572029de2e5baece60cddf6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55225
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
The clang script needed to be tweaked slightly because they've since
changed the URL. Also libc++ now needs to be built as C++20. (The
bundled libc++ is only built in some of our test configs, so this
doesn't imply a C++20 dependency across the board.)
Change-Id: I0a9e3aed71268bcd37059af8549a23cfc0270b05
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55272
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
CMake 3.10 was released November 20, 2017, which is now more than five
years ago.
Change-Id: Ic939fd137983914ce1041740f58d98a56433e739
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55271
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
ioutil has been deprecated since Go 1.16. The functions were moved to
some combination of io and os. See https://pkg.go.dev/io/ioutil.
(File-related functions went to os. Generic things went to io. Names
were kept the same except TempDir and TempFile are os.MkdirTemp and
os.CreateTemp, respectively.)
Change-Id: I031306f69e70424841df08f64fa9d90f31780928
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55186
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The indices do fit in unsigned, but we're not taking any advantage of
this because of struct padding, and the RSA structure is not that
memory-sensitive.
Bug: 516
Change-Id: I678e20fcd6f6fa8f69eaef1f4108fa94194b6ee7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55270
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
One less function to make size_t-clean.
Update-Note: All callers of this function since been removed.
Change-Id: I4cd77ede5f58cdbc3cf65365a8fd23967545ecfa
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55269
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
ASN1_ENCODING has a 'modified' bit, but every time it is set, the
contents are both ignored and never filled in again (we don't fill in
the encoding except on parse). That means keeping the underlying buffer
around is just wasting memory. Remove the bit and use the len != 0 to
determine if there's a saved encoding. Replace all the modified bits
with a helper function that drops the encoding.
I don't think we need a separate "present" boolean and can just treat
empty as not saved; a cached value always has a tag and length, so it
cannot be empty. (Even if it could be empty, that would imply the
value's encoding is trivial enough that we probably don't need the saved
encoding to preserve the value.)
Change-Id: I6beda94d33f3799daf85f1397818b9a41e7dd18a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55267
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This probably needs some revising (ideally the files would just live in
some BoringSSL branch), but for now just avoid undoing the manual change
done to the pregenerated files in Chromium.
Change-Id: I0435a1478af8265c085d316eb83b394289eb1f67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55245
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We use unsigned, but we actually assume it is 32-bit for the bit-packing
strategy. But also introduce a typedef to hint that callers shouldn't
treat it as an arbitrary 32-bit integer. A typedef would also allow us
to extend to uint64_t in the future, if we ever need to.
Update-Note: Some APIs switch from unsigned * to uint32_t * out
pointers. This is only source-compatible if unsigned and uint32_t are
the exact same type. The CQ suggests this is indeed true. If they are
not, replace unsigned with CBS_ASN1_TAG to fix the build.
Bug: 525
Change-Id: I45cbe127c1aa252f5f6a169dca2e44d1e6e1d669
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54986
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I had a rewrite of the decrepit ciphers (CAST and Blowfish) to use
CRYPTO_{load,store}_u32_be and drop the old macros, but this is probably
not worth the effort to review. Instead, just fix the type in the macro.
Bug: 516
Change-Id: I1cdecc16f6108a6235f90cf9c2198bc797c6716e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54985
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We have a number of APIs that cannot migrate to size_t because OpenSSL
used negative numbers as some special indicator. This makes it hard to
become size_t-clean.
However, in reality, the largest buffer size is SSIZE_MAX, or, more
accurately PTRDIFF_MAX. But every platform I've ever seen make ptrdiff_t
and size_t the same size. malloc is just obligated to fail allocations
that don't fit in ssize_t. ssize_t itself is not portable (Windows
doesn't have it), but we can define ossl_ssize_t to be ptrdiff_t.
OpenSSL also has an ossl_ssize_t (though they don't use it much), so
we're also improving compatibility.
Start this out with ASN1_STRING_set. It still internally refuses to
construct a string bigger than INT_MAX; the struct can't hold this and
even if we fix the struct, no other code, inside or outside the library,
can tolerate it. But now code which passes in a size_t (including our
own) can do so without overflow.
Bug: 428, 516
Change-Id: I17aa6971733f34dfda7d971882d0f062e92340e9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54953
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This aligns with upstream's f72f00d49549c6620d7101f5e9bf7963da6df9ee. In
doing so, I had to fill in a bunch of NULL checks in p_ec_asn1.c, to
account for EVP's needlessly many "empty" states. For now, those cases
return a goofy -2 to align with upstream. Our EVP_PKEY_cmp_parameters
still returns negative values, so this is fine, though ideally we'd
narrow to boolean. That probably depends on some other changes. See
https://crbug.com/boringssl/536#c3.
Bug: 536
Change-Id: I1124c8ad5223ac23953d94ff9ca734fbb714e89c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55185
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The counter is accessed as x2, not w2, so this is a uint64_t parameter.
Change-Id: I97a5dabc521fc00fc366a67712bc4932b256532f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55145
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
I missed this in
https://boringssl-review.googlesource.com/c/boringssl/+/54905.
Upstream's 2986ecdc08016de978f1134315623778420b51e5 also made copying
into EVP_PKEY_NONE allowed.
For those keeping score, this gives us *even more* layers of empty
states:
- EVP_PKEY with no type
- EVP_PKEY with type but no key
- EVP_PKEY with type and EC_KEY but EC_KEY is empty
- EVP_PKEY with type and EC_KEY and EC_KEY only has a group
To say nothing of the states in https://crbug.com/boringssl/534. This
API is not good.
Bug: b:238920520
Change-Id: I49e85af5b02b16724454999ccb7c61b520d8c99c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55165
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
OpenSSL uses integer parameters for this function, and the
multiplication here ends up being done as an integer. Since we
support values up to year 9999, it is possible for someone to pass
in a number of days to the "adj" function to adjust a base time far
enough to overflow a 32 bit integer.
Change-Id: Iedfc33d8bf90d70049f99897df1d193fb29805d0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55125
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Should the string be INT_MAX, we cannot actually represent the output
length. i2c_ASN1_INTEGER and ASN1_object_size have checks this, but this
was missing it.
Change-Id: I7cf5debb87568b876f3799308ef4ad6d2b1ff7e6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55085
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
OpenSSL added a bunch of these. oct2priv is a little weird (see
https://crbug.com/boringssl/534), but I've made it match OpenSSL and
set_private_key for now. But I think we should reduce the state-space a
bit.
EC_KEY_oct2priv behaves slightly differently from upstream OpenSSL in
one way: we reject inputs that aren't exactly the right size. This
matches the OpenSSL documentation (the OCTET STRING inside an
ECPrivateKey, per spec, is fixed-width), but not OpenSSL's behavior.
Update-note: see go/xshow when incorporating this change internally.
Change-Id: I33863d773ac4c7f3eabf4ffda157e8250c7fdbd9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55066
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/41084
inadvertently added a somewhat expensive operation (field inversion) in
the path of EC_POINT_point2oct when passed with buf == NULL. The result
is a caller that calls the function twice, first to measure and then to
serialize, actually ends up doing the field inversion twice.
Fix this by removing the dual-use calling convention from the internal
function and just have a separate function to measure the output size
separately. It's slightly subtle because EC_POINT_point2oct would check
for the point at infinity by way of converting to affine coordinates, so
we do need to repeat that check.
As part of this, add a unit test for
https://boringssl-review.googlesource.com/6488, which rejected the point
at infinity way back.
Change-Id: I3b6c0f95cced9c00489386f064a2c3f0bb1776f8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55065
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
SSL_export_keying_material can only be used when the exporter secret is
available, e.g. during False Start (TLS 1.2) and on the server when
processing 0-RTT (TLS 1.3). These conditions were special cased, but
there is at least one more case in TLS 1.3 where the exporter secret is
available. This change switches the logic for TLS 1.3 to check whether
the exporter secret has been derived and makes
SSL_export_keying_material functional if it has, instead of checking if
the handshake is in one of some number of specified states.
Allowing the availability of the exporter in TLS 1.3 on the server after
processing the client's handshake flight and sending the server Finished
is equivalent to the already-allowed case of exposing the exporter in
TLS 1.2 False Start.
Bug: b:255591447
Change-Id: Ib216fd4a676524a777aae17569161c02dd2e40ca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55025
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Nick Harper <nharper@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
This is a departure from OpenSSL's output (which seems to just append
even more information afterwards), but is a better way to identify the
algorithm.
Change-Id: Iccffdf9297bde5362d902d4de1d99de7b673bed2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54952
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also build with -Wtype-limits to catch future instances.
Bug: 529
Change-Id: I2d84dc1824ffc7cd92411f49c9f953bcd3c74331
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55045
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
BIO_hexdump does not really fit here. This matches OpenSSL.
Change-Id: I5c8e2b992c2711fb7986aa549578da9495360536
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54951
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This seems to just have been a bug. OpenSSL partially fixed it in
https://github.com/openssl/openssl/pull/9983, but upstream's fix
duplicated some logic and outputs "Public-Key" in the ptype == 0
(parameters) case.
Change-Id: I2c669c1cb1a4af50858afd5b1179d3550f3c119a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54950
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Aligning the bn_print labels doesn't do anything. They will, almost all
the time, add a newline anyway.
Change-Id: Ib6571eba7508ebd46508c61a68bfbb03d8c52ba6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54949
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This reverts commit 64393b57e8. We'll
reland this change in January. Projects that rely on this revert should
use SSL_set_enforce_rsa_key_usage, available since 2019, to control the
security check without being reliant on the defaults.
Bug: 519
Change-Id: Icf53eae8c29f316c7df4ec1a7c16626ac3af8560
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55005
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
First, stop trying to pre-size the buffer and just have bn_print
allocate the buffer internally. That removes the need for all the
algorithms being two-pass.
While I'm here, stop passing the unused ASN1_PCTX parameters in
everywhere.
As a side effect, this fixes a int vs size_t instance that flagged
-Wshorten-64-32, but it ended up being a much more substantial change.
Bug: 516
Change-Id: Ic210604de85539559b1ed88889ca6a08dfb20bde
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54948
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
These are mostly to ensure they don't crash, and that subsequent changes
don't unintentionally change the output. The current output is a little
weird but, for now, I've just captured the current output, bugs and all.
Change-Id: I9f1a4910ccc717764ef44551de9b3e0f9f2a1b40
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54947
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We shouldn't print different things depending on sizeof(long).
Change-Id: I5f97e17b838f8c9b119421b9ce0e93e95bd33dc0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54946
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Bug: 516
Change-Id: Iba2014da414658c08e42e0993912fa73848832d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54945
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Some third-party code requires it.
For now, I've just introduced a new hook on the method table. This is
rather goofy though. First, making EVP know about TLS is a layering
violation that OpenSSL introduced. They've since fixed this and added
EVP_PKEY_get1_encoded_public_key in OpenSSL 3.0, but callers expect the
TLS one to exist in OpenSSL 1.1.1, so implement that one.
Along the way, implement EC_KEY_oct2key from upstream, which is slightly
less tedious when you're already working in EC_KEY.
To make this third-party code work (and to write a test without dipping
out of EVP, or using the very tedious EVP_PKEY_paramgen API), we also
need to change EVP_PKEY_copy_parameters to work when the source EVP_PKEY
is empty, per upstream's 2986ecdc08016de978f1134315623778420b51e5.
OpenSSL's API has *multiple* levels of empty states to worry about!
Something to avoid when we get to rethinking this error-prone API.
Bug: b:238920520
Change-Id: I3fd99be560db313c1bf549a4e46ffccc31e746e1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54905
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This adds the link libraries in CMakeLists.txt file. If the libraries
are not in CMake files linking failed with undefined reference error.
Change-Id: I8f8352f6149a6332eedc0be51f36634890e3db60
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54805
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Previously the code just flipped one bit. But, empirically, modern Clang
will sometimes produce code that doesn't depend on the first 16 bytes of
the data; they are encoded in the instructions instead. Thus zero out
the full value.
(If Clang ever starts embedding complete values into the instruction
stream then we're going to have to do something more complex. Self tests
are a bit funny: the compiler could reasonably optimise them away
completely given that it sees all the inputs. Perhaps the inputs would
have to be moved into a different object file.)
Change-Id: I7bfb18cb7868def67fc791dcc31c5915c7728ac4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54825
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Newer versions of Clang have a warning to detect "suspicious" uses of
string concatenation, where they think a comma or so was missing. It
flags a false positive in x509_test.cc, which we can silence with
parentheses. Fuchsia builds with this warning enabled, so enable it to
catch future instances.
I couldn't find official documentation on when this was added, but
empirically it's in my clang-12 but not my clang-11. That's recent
enough that adding a version check seems prudent. Unfortunately,
version-detecting Clang is complex because AppleClang uses completely
different versions. There's a handy table on Wikipedia that maps them.
Change-Id: I503c21d39bb5c68dda9bda6da693c7208f3af561
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54785
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
While I'm here, use a fixed-size uint64_t in RSA_generate_key, rather
than unsigned long. This code also assumes unsigned long fits in
BN_ULONG, which is probably true on all platforms we care about, but
unnecessarily fussy.
The RSA_sign -> RSA_METHOD transition does require a cast. Go ahead and
check length/hash_nid consistency so we know it fits in the cast. This
does mean RSA_METHOD-backed keys are restricted to implementing digests
that we support, but that's probably fine. If anything, I think we
should try to shift away from RSA_METHOD as a story for custom keys.
Bug: 516
Change-Id: I3969da67d1daeff882279a534eb48ca831eb16cd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54465
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>
I messed up the indentation in one place, and Shane Lontis pointed out
that the comment is slightly out of date now that there are two
codepaths involved.
Change-Id: I1be69f3f9a3835fffc4801b4464b9fb8ecb092cc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54745
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
A small follow-up to
https://boringssl-review.googlesource.com/c/boringssl/+/54105, to bring
it up to feature parity with the other aarch64 backends.
ID_AA64ISAR0_SHA2_512 seems to be present in FreeBSD 12.0, so I don't
believe this needs any compatibility ifdefs.
Bug: 505
Change-Id: I44891cf635adfd2ae26d4113fdc910549cf89193
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54725
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Robert Clausecker <fuzxxl@gmail.com>
Reviewed-by: Bob Beck <bbe@google.com>
We don't actually refresh the cache most of the time, just drop it and
live without it. The distinction isn't really visible by callers, but
make the comments accurate.
Change-Id: I7321695337125ca648ab57667564d9578a6fd549
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54727
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We didn't actually have a test that would have caught
https://github.com/openssl/openssl/issues/19388. This fixes this by
further generalizing the signing tests to run through all combinations
of {new object, reused object} x {X509_sign, X509_set_signature_value}.
In doing so, align X509_REQ_sign and X509_REQ_sign_ctx, which were
missing the TBS invalidation.
Change-Id: I5028aa2a00e71da0ebc7a03b23823b1337a56fca
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54726
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
cbb_add_utf8 is CBB-based, so it is bounds-checked.
Change-Id: Ib30272255894d7d3a35a164a5eefcdce9e8e7991
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54646
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
CBB_init_fixed callers no longer need to check the return value, or
handle any cleanup. The hpke.c instance was even already (incorrectly at
the time) assuming this.
Change-Id: I2f4cb124454fc7ba7ff6d2075d99f537a58c6c6b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54647
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Today, every use of CBB, even CBB_init_fixed, requires a small, fallible
allocation to allocate the top-level CBB's cbb_buffer_st. We could embed
cbb_buffer_st directly in CBB, but then every child CBB wastes that
space, and needs an extra pointer to point back to the cbb_buffer_st.
But top-level and child CBBs have disjoint representations anyway. We
share a cbb_buffer_st pointer, but it's owning in one case and
borrowed in another. Child CBBs have length prefix information, but it's
never filed in for a top-level CBB.
Make this a sum type, with is_child as the discriminator and a union for
the two structures. (Elsewhere I've been trying to get rid of unions,
but this isn't using unions for type-punning, so it should valid even in
C++. We never access inactive arms.)
The implementation gains a few more branches, but now CBB_init_fixed is
infallible and allocation-less. I'm hoping this will let us more freely
convert functions like UTF8_putc into CBB because we don't need to worry
about cleanup or introducing allocations.
Change-Id: If0b28cd9e079418f35d5a614058c0aa73658822e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54645
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin
Bob Beck
Adam Langley
Nick Harper
Biswapriyo Nath
Sergey A. Osokin