Change-Id: I330ac0fa7f0b2c9984d12da831d8f34019ea2c49
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58526
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>

Change-Id: I6e53434246f3fef06d4f88924bfe1cbfad0543e8
Bug: chromium:1414562
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58205
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>

Thanks to wangjiale3 for noticing a leak of ext_oct on malloc error in
https://boringssl-review.googlesource.com/c/boringssl/+/58488. This is a
fixed version of that CL, and also fixes a leak of ext_der on malloc
failure.

Change-Id: I2c7ece6b2950a9cb807d78e72b2fddc21897a019
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58686
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

Bug: 586
Change-Id: I5bc8e6df3a5a14e6b218f41181d06406e835f9c1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58605
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

This reverts a small portion of
8c8629b. The parsers for ANY remain
unchanged, but we inadvertently changed a corner case of ASN1_PRINTABLE
MSTRINGs. This is a huge mess.

utype in these switch cases is usually the type of the ASN1_ITEM, but,
with ANY and MSTRING, it is the tag of the value we found. (An MSTRING
or "multi-string" is a CHOICE of string-like types.)

When parsing ANY, this is moot because the is_supported_universal_type
logic ensures we'll never pass in an invalid type. When encoding ANY,
this only happens if you manually construct such an ASN1_TYPE.

MSTRINGs *should* be similar because of the bitmask they apply on tag
types. However, there is one MSTRING type whose bitmask,
B_ASN1_PRINTABLE, includes B_ASN1_UNKNOWN. ASN1_tag2bit, arbitrarily
maps eight unsupported tags to B_ASN1_UNKNOWN and instead of zero. These
are:

- ObjectDescriptor
- EXTERNAL
- REAL
- EMBEDDED PDV
- RELATIVE-OID
- TIME (note this is not the same as the X.509 Time CHOICE type)
- [UNIVERSAL 15], which is not even a defined type!
- CHARACTER STRING

(ENUMERATED is also mapped to B_ASN1_UNKNOWN, but it's supported.)

These eight tags were previously accepted in d2i_X509_NAME but
8c8629b inadvertently started rejecting
them. For now, restore the default in the switch/case so that we accept
them again. Per https://crbug.com/boringssl/412, attribute values are
ANY DEFINED BY types, so we actually should be accepting *all* types. We
do not, because B_ASN1_PRINTABLE is completely incoherent. But because
ANY is the correct type, going from the original incoherent set, to
this new, smaller incoherent set is arguably a regression.

This is a minimal fix. Long-term, we should handle that ANY correctly,
and avoid unexpected ASN1_STRING type values, by mapping all unsupported
types to V_ASN1_OTHER. This would allow us to support all types
correctly. A follow-up change will do that.

Update-Note: The X.509 name parser will go back to accepting a handful
of universal tag types that were inadvertently rejected in
8c8629b. It is extremely unlikely that
anyone uses these as they're unsupported, obscure types. This CL also
makes our ASN1_TYPE encoder slightly more permissive again, if the
caller manually constructs an legacy in-memory representation of an
unsupported tag. But the follow-up change will restore the stricter
behavior.

Bug: 412, 561
Change-Id: Ia44a270f12f3021154761a1cd285707416d8787e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58705
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

I don't believe these codepaths have ever been run. All the built-in
X509V3_EXT_METHODs are ASN1_ITEM-based, as are all callers I found of
X509V3_EXT_add and X509V3_EXT_add_list.

Also document not to use those APIs because they're pointless and (for
now) not even thread-safe. Making them thread-safe is doable, but it'd
add rwlock contention in certificate verification, unless we first
rework certificate verification to ignore custom registrations, because
it never uses them anyway. But that only proves that this whole feature
was pointless, so this time may be better spent trying to get rid of
this API.

Update-Note: Externally-installed X509V3_EXT_METHODs now must be
ASN1_ITEM-based. I believe all existing ones already are. If there are
any that aren't, let us know. We'll either revert this for now, or
export a way to implement custom ASN1_ITEMs, or, most likely, try to
move the caller off custom X509V3_EXT_METHODs altogether. Like most of
OpenSSL's other global registration APIs, this one is unsafe (two
callers may conflict) and there isn't much reason to register it with
the library because OpenSSL doesn't do much with the registration
anyway.

Bug: 590
Change-Id: Ice0e246d50069e10e6cca8949f60fac474d0846c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58687
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

These are already unused, though add and add_alias will need more work.

In doing so, simplify the X509V3_EXT_DYNAMIC business. I added some
cleanup calls to https://boringssl-review.googlesource.com/2208, but
that should have been in the error-handling path of
X509V3_EXT_add_alias, the only case that cares about this.

Update-Note: Removed unused API.

Bug: 590
Change-Id: Idd97366d90d7aab0ca2e020c76a7c8065b3dd7ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58765
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>

…its original state keeping the same key as initially used

Change-Id: Ie781e2a20da26b50b34f35ea0a5cfc578b64ee7f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58565
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

HRSS itself remains in libcrypto because there are some direct users of
it. But this will let it be dropped by the linker in many cases.

Change-Id: I870eda30c9ed1d08693c770e9e7df45a2711b7df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58645
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

Change-Id: I7c5b0a24c26b83779cf889d890e2c18ae13187c3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58725
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

Change-Id: I32a40a73f96e029ac9096af826d15b22d9dcad28
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58745
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

…icer with other build systems like Soong and Gn.

Change-Id: I42e40da22dd243796cd735e09a9821cc2d114200
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58785
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

Change-Id: Ib3372c2a4e0e6189402485e87963d8151ad29981
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58786
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: Bob Beck <bbe@google.com>

This relands
https://boringssl-review.googlesource.com/c/boringssl/+/54606, which was
temporarily reverted.

Update-Note: By default, clients will now require RSA server
certificates used in TLS 1.2 and earlier to include the keyEncipherment
or digitalSignature bit. keyEncipherment is required if using RSA key
exchange. digitalSignature is required if using ECDHE_RSA key exchange.

If unsure, TLS RSA server signatures should include both, but some
deployments may wish to include only one if separating keys, or simply
disabling RSA key exchange. The latter is useful to mitigate either the
Bleichenbacher attack (from 1998, most recently resurfaced in 2017 as
ROBOT), or to strengthen TLS 1.3 downgrade protections, which is
particularly important for enterprise environments using client
certificates (aka "mTLS") because, prior to TLS 1.3, the TLS client
certificate flow was insufficiently encrypted or authenticated. Without
reflecting an RSA key exchange disable into key usage, and then the
client checking it, an attacker can spoof a CertificateRequest as coming
from some server.

This aligns with standard security requirements for using X.509
certificates, specified in RFC 5280, section 4.2.1.3, and reiterated in
TLS as early as TLS 1.0, RFC 2246, section 7.4.2, published 24 years ago
on January 1999. Constraints on usage of keys are important to mitigate
cross-protocol attacks, a class of cryptographic attacks that is
well-studied in the literature.

We already checked this for each of ECDSA, TLS 1.3, and servers
verifying client certificates, so this just fills in the remaining hole.
As a result, this change is also important for avoiding some weird
behaviors when configuration changes transition a server in or out of
this hole. (We've seen connection failures get misattributed to TLS 1.3
when it was really a certificate misconfiguration.)

Chrome has also enforced this for some time with publicly-trusted
certificates. As a temporary measure for callers that need more time,
the SSL_set_enforce_rsa_key_usage API, added to BoringSSL in January
2019, still exists where we need to turn this off.

Fixed: 519
Change-Id: I91bf2cfb04c92aec7875e640f90ba6f837146dc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58805
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

NIST has deprecated the test that we were using and replaced it with the
one that this change switches BoringSSL to using.

Change-Id: Iff975cda33153f8db42d9c01457d104c502485b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58787
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

On Android, when running from an APK, |tmpfile| does not work. See
b/36991167#comment8.

Change-Id: I1415471907e61da5e8c8d1530a2b915fcd991d53
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58845
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

(This change breaks running on Android. But it's close to what we used
for non-Android FIPS testing so is useful to have on the record.)

This change adds testing of the run-time break tests: the pair-wise
consistency tests and the RNG test.

It also switches to using two test_fips binaries: an unmodified one for
showing a clean up and testing the integrity test, and a test_fips_break
which makes integrity test failures non-fatal (for KAT testing) and
which allows the run-time tests to be triggered.

Change-Id: Id2787723059cfb17cc2d22013ad66b985ef86701
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53885
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

Change-Id: Ibe428995fbc03669bf822296741574e2bbeb482d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58865
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

Bug: 516
Change-Id: I3f374f05188bebe7aa4cbf45c81a6f945d3ce97c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58549
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

Change-Id: I2218807c6bfe445460a01f6c86712640915e87df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57666
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

I had a branch lying around to rewrite X509_NAME_print(_ex) because
those functions are a disaster, but it needs more work and probably
isn't high priority. In the meantime, document what we've got.

Also tidy up X509_print_ex slightly. m was completely unused and
some variable declarations could be moved closer to their definition.

Bug: 426
Change-Id: I24295048c36268c745f579ad66f34736cfe6830f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58925
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>

Also organize the low-level signature verification functions. I missed
those in the first pass.

Bug: 426
Change-Id: I9c93d643d8f0f77a35ee132f31377ba447f2f2f1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58926
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

They're not used anywhere, as X509_REQ doesn't expose the underlying
STACK_OF(X509_ATTRIBUTE) anyway. They're also very thin wrappers over
the stack functions, so just delete them and inline them into X509_REQ
functions.

While I'm here, I've tidied up the add1_attr_by_* functions to reduce an
unnecessary copy.

Change-Id: Iec002c83ab7ad7267314e98866d680d12a82e971
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58927
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

These probably don't need their own section. They're just thin wrappers
over other ASN1_TIME functions.

Bug: 426
Change-Id: I8672feb0ca7ba1cf69b56d02d2559de5b80a3ee7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58928
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

Change-Id: I54195f3fabbed788d3cf299d478d5151acfe2a4f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58929
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

This has been on by default since
rust-lang/rust-bindgen@cc78b6f,
and now removed from recent bindgen altogether.

Change-Id: Iea4c2a7480fe8b138c375686ca6b36e6d68257b3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58965
Reviewed-by: Nabil Wadih <nwadih@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

These appear to be unused. Some ones of note:

- XN_FLAG_FN_ALIGN breaks with multi-attribute RDNs anyway
- XN_FLAG_FN_NONE is completely pointless

Update-Note: Some seemingly unused XN_FLAG_* values were removed. If
some project fails to build, we can put them back but one shouldn't be
using this function in the first place.

Change-Id: I4d8472e1e31aeec623b4d4e2aea48da7b1ef6798
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58930
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

Newer CMakes support a -B parameter, which saves some fuss.

Change-Id: Ifdbbb50b3720cdc42af098eb32941283692e9d99
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58966
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Nabil Wadih <nwadih@google.com>

The allowlist is just a regex, which means bindgen leaves it to the
user to resolve Windows vs POSIX filepath differences. We need to
support both / and \. It's unclear why only some headers are broken, but
it's probably something to do with whether the header is included
directly or indirectly.

Unfortunately, in doing so, we run into a mess of escaping issues, so
the regex is more permissing than ideal.

Bug: 595
Change-Id: I8b785aeaaeff162d9eb2aced89928f9602445903
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58967
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

Change-Id: I6e0361a42b9612ba4294cc8806203ea445bc9257
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58945
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

We already require that #include <openssl/blah.h> work. May as well be
consistent in wrapper.h, so it's less path-sensitive.

Change-Id: Idd12e1c56a6e5d11623b4da82e405a5e976601b0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59045
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

This allows us to mark functions as deprecated
declarations with OPENSSL_DEPRECATED.

We also add an OPENSSL_BEGIN_ALLOW_DEPRECATED and an
OPENSSL_END_ALLOW_DEPRECATED for testing use to
test deprecated functions.

The purpose of this is to allow us to mark things
people should not be using as deprecated, and force some
inconvenience on the user of such things to notice them
(as opposed to a only a warning to not use it that they
may not see or read without something tripping them up.)

The intent is to still allow use, with some effort,
before removing the function, or moving it to
libdecrepit.

We initially mark X509V3_EXT_add and X509V3_EXT_add_alias
as deprecated.

Update-Note: We are starting to mark some functions in
boringssl as deprecated declarations which will cause the
compiler to emit warnings if they are used. The intention
is both to prevent accidental use in new code, and to to call
attention to call sites in existing code so that the documentation
for the deprecated function can be revisted and appropriate action
taken.

Bug: 584
Change-Id: Ia9ff386f0d22588e8a5999eda1a48b8c28dca2de
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58405
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

This took a bit of wrangling to get the depfiles working, but I
eventually figured it out. ninja -d explain is very useful.

Fixed: 597
Change-Id: I909a4c9418e9dc954e3d328da8f3a825e62544e4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59005
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

Per b/31553927, the last use of this is long gone. This cipher has been
deprecated since it was (re)-added in 2015, so it's long past time to
remove it.

Update-Note: TLS_RSA_WITH_NULL_SHA is no longer available. Nothing
should be enabling it anymore. Callers using
SSL_CTX_set_strict_cipher_list instead of SSL_CTX_set_cipher_list will
notice if they're affected very quickly, because the functino will
fail if this cipher is referenced. As a deprecated cipher suite, this
cipher was already unavailable unless explicitly named, so if your
configuration doesn't say "TLS_RSA_WITH_NULL_SHA" or "NULL-SHA", you
were not using this cipher.

Bug: b:31553927
Change-Id: Id560bb4f9b156be3650d63f4ecf7783fad5ae209
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>

Add a new flag, -shim-extra-flags, which allows specifying additional
flags to pass to the shim binary on all invocations. These flags will be
passed as the first flags to the shim in order to take advantage of some
slightly confusing Go flag semantics.

Change-Id: I382f47bfe2662903b43135fcb249b46646fc9e7b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59245
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

This can still be run like go run ../../util/convert_wycheproof. This is
part of an attempt to reland 54b04fd,
which ran into an issue with internal tooling that could not handle
standalone Go files.

Since the only such target we actually needed to run in that repository
is convert_wycheproof, just promote it into its own package. Then we can
stop trying to import util.

Change-Id: I6237777dad09e5c81ad961816ce14a287ab2d46a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59185
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>

This reverts commit bab2f96. This
clears the sea of red in my editor.

Change-Id: I600ef6c36556fb526da729f0f0d8bc69db5c5a08
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59186
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

This aligns the DLEQ proof portion of TRUST_TOKEN_pst_v1_voprf
with draft-irtf-cfrg-voprf-21. The blind and finalize operations
still differ. Additionally, as VOPRF doesn't include batched
issuance, the issuance process around the DLEQ proof is adapted
from draft-robert-privacypass-batched-tokens-01.

Bug: chromium:1414562
Change-Id: If1c6de0f92089a826968a57279ae598ccf89ca3e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58906
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>

We were currently squeezing 3 bytes at a time. And because kyber.c and
keccak.c are separate files, we've got an optimization barrier, at least
in non-LTO builds, at a very inconvenient place.

Instead, extract the full 168 bytes (SHAKE-128 rate) at a time. This is
conveniently a multiple of three, so we don't need to worry about
partial coefficients. We're still doing a copy due to the Keccak
abstraction, but it should extend cleanly to either LTO or a different
abstraction to read from the state directly. Even without that, it's a
significant perf win.

Benchmarks on an M1:

Before:
Did 87390 Kyber generate + decap operations in 4001590us (21838.8 ops/sec)
Did 119000 Kyber parse + encap operations in 4009460us (29679.8 ops/sec)

After:
Did 96747 Kyber generate + decap operations in 4003687us (24164.5 ops/sec) [+10.6%]
Did 152000 Kyber parse + encap operations in 4018360us (37826.4 ops/sec) [+27.4%]

Change-Id: Iada393edf0c634b7410a34374fb90242a392a9d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59265
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

We previously used the functions from the cipher language to define it,
but it's more straightforward to just list them out.

Change-Id: I1467d6db47a93c8443a0a448ef974c827b1b3233
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59146
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

When building BCM sources individually, this gets missed.

Change-Id: I58858da441daaeffc5e54b653f5436fe817c4178
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59306
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>

Prior to https://boringssl-review.googlesource.com/c/boringssl/+/58548,
ASN1_item_sign_ctx returned the length of the signature on success. It's
unclear why anyone would ever want this, but some test was sensitive to
it. (I think it was a typo.)

Restore the old behavior.

Change-Id: Ibf3e45331a339226744d51df703634d02b08a7c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59307
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>

The reason to make it a package was to avoid needing this, but I missed
that git put it back.

Change-Id: Idd6df275aa964083db525d4d5e300128b204d973
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59305
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>

Instead, just have it look for the files it needs via a
BORINGSSL_BUILD_DIR environment variable. This avoids hardcoding
"../../build" anywhere that cannot be easily overriden by the user.

Although this puts logic in a build.rs file, which is problematic for
repositories with more coherent build stories like Android or Chromium,
those are already driving the bindgen and link process themselves,
without calling CMake. I.e. this file should already only be used for
standalone development and testing and not directly impact them. (Though
we'd like to keep it vaguely analogous to better predict without a
change will impact downstream folks.)

For now, I've kept bindgen generated from CMake, mostly in anticipation
of using the inline functions feature. Building the synthesized C file
from CMake seems less of a headache than Cargo. Additionally, calling
bindgen from the command-line is closer to how those consumers will do
it, so this forces us to stick to bindgen invocations that can be
expressed via command-line arguments. (E.g. the mess that is regexes and
escaping.)

As part of this, I've removed the messy "find the first matching wrapper
file" behavior in build.rs. Instead, it knows the expected TARGET and
just finds the file with matching name. This means we'll be stricter
about matching the two. (Otherwise there's no point in naming it by
target name anyway.)

Fixed: 598
Change-Id: I07fa74f7e5f5f008d6f0ceec648a2378df7d317a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59105
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Nabil Wadih <nwadih@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>

We have since added an implementation of a subset of the SSL BIO, but we
don't implement all the features, notably some of the BIO_ctrl values.
Remove them, so it doesn't look like they should work.

Update-Note: I found no code using those symbols (that we build). If
anything was, they most likely were broken. Now they'll fail to build
and the brokenness will be more obvious. (If we find something needs it,
we can always go back and implement them.)

Fixed: 420
Change-Id: Iad03fa65f098023dca555a9b2ac0214ba4264546
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59125
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>

Also fixes some copy-paste errors in earlier docs.

Bug: 426
Change-Id: I330445477b6feb50f65a868130387804114f23a8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59205
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

AllCurves interferes with cross-version handshake hint tests. If any
curve is removed, the test breaks. This is a particular nuisance for
signing tests, where we'd rather like to see cross-version hint
compatibility. It's also a nuisance for writing test suppressions
because the remove curve is not actually listed in the test name.

The signing tests don't actually need to enable all curves. They just
need to handle some TLS 1.2 ECDSA rules. Fix that by having the test
know the expected curve and to configure it explicitly. Hopefully
that'll reduce the exceptions needed in the future.

Change-Id: I432e084c49a943afc92726ccf0b73658e7bd30b1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59325
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>

It's unwise for organisations to try and define TLS profiles. As in this
case, they usually make security worse. However, since this is already
established and supported by Android, this change raises it to the level
of a supported policy.

Change-Id: Ic66d5eaa33d884e57fc6d8eb922d86882b621e9e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58626
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>

As part of getting a handle on RSA state, I would like for RSA keys
created from parsing to come pre-"frozen". This reduces some contention
on first use. But that potentially breaks an existing use case: today,
you're allowed to parse a private key and then override one field
without problems, because none of the cached state has materialized yet.

If the caller modified the RSA key by reaching into the struct, it's
hopeless. If they used the setters, we actually can handle it correctly,
so go ahead and make this work.

DH and DSA aren't of particular interest to us, but fix them while I'm
at it.

This also avoids having to later document that something doesn't work,
just that it's a terrible API.

Bug: 316
Change-Id: Idf02c777b932a62df9396e21de459381455950e0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59385
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

Change-Id: I49920d3917f0aebf1b9efbd45d0bcd944d6c8117
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59405
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>

Per the bug discussion, FreeBSD seems to default to a cap of 1500
threads per process. Just turn the test off.

But enable the test unconditionally if building with TSan. With TSan on,
we only spawn two threads, which should be within everyone's bounds.

Fixed: 603
Change-Id: Ic8c49e5ce7c3f2d09487debc72b7e4c54b04a77c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59445
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

This adds APIs for constructing RSA keys given all the parameters. This
is much less tedious than the set0 functions, and also avoids issues
caused by deferred initialization.

It doesn't quite finish initializing the keys on construction, as that
is tied up in the rest of this mess. But later work, probably after
Conscrypt is moved to these APIs, will do this.

As part of this, add APIs that explicitly create RSA keys with no e.
There is actually no way to do this right now without reaching into
library internals, because RSA_set0_key refuses to accept an e-less
private key. Handle this by adding a flag.

I also had to add a path for Conscrypt to make an RSA_METHOD-backed key
with n but no e. (They need n to compute RSA-PSS padding.) I think that
all wants to be rethought but, for now, just add an API for it.

This bumps BORINGSSL_API_VERSION so Conscrypt can have an easier time
switching to the new APIs.

Bug: 316
Change-Id: I81498a7d0690886842016c3680ea27d1ee0fa490
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59386
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>

Satisfy a go lint. As of Go 1.18, any is the preferred spelling of
interface{}.

Also remove an instance of redundant types in
util/fipstools/acvp/acvptool/acvp.go because my editor warned about it.
(A []map[string]any{map[string]any{...}, map[string]any{...}} literal
can omit the inner copy of the type because it's implicit from the outer
one.)

Change-Id: I2251b2285c16c19bc779fa41d1011f7fa1392563
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59465
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>

It is now RFC 8452. The final RFC also has a few more test vectors, so
import those too.

Change-Id: Ib7667802973df7733ba981f16ef6a129cb4f62e7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59485
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>

Relevant spec bits:
https://www.rfc-editor.org/rfc/rfc9180.html#section-4.1
https://www.rfc-editor.org/rfc/rfc9180.html#section-5.1.3

Change-Id: Iddb151afc92f7a91beb9ca52caceec6cb5383206
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59387
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>

…he FIPS module.

…or MSVC