In doing so, this switches make_errors.go to take library names as
parameters rather than detecting it from the CWD. (I considered
detecting it, but then we'd need to map evp -> crypto/whatever and
crypto/whatever -> evp in both directions.)
Since crypto/hpke currently sits in the EVP namespace, I've gone ahead
and added that, so it should be easier to define new errors in
crypto/hpke. I've not added crypto/cipher, etc., yet. Moving those will
be a breaking change (consumers that put ERR_LIB_CIPHER and ERR_LIB_EVP
in a switch/case need patches).
Bug: 398
Change-Id: Ibae2afd46e076891fa517c377b540b2e492516f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46264
Reviewed-by: Adam Langley <agl@google.com>
This is a little inconvenient for external users of the test suite. It's
also not very helpful to pass -handshaker-path in build configurations
without a handshaker because there won't be a file there anyway.
Change-Id: I6a8fdcfbbf86288876c4c6fda2a46d32663efb69
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46244
Reviewed-by: Adam Langley <agl@google.com>
The build scripts distinguish between normal files and bcm.c fragments
based on whether code is in a subdirectory inside crypto/fipsmodule.
Bug: 401
Change-Id: Ieba88178e4f8e19f020e56e2567d5736a34bb43f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46224
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
See draft-davidben-tls13-pkcs1-00. The code point is disabled by default
and must be configured in SSL_set_verify_algorithm_prefs and
SSL_set_signing_algorithm_prefs. It is also only defined for TLS 1.3
client certificates and otherwise ignored.
This required reworking the tests a bit since this is the first
signature algorithm that's disabled by default, and the first algorithm
that behaves differently between client and server.
Change-Id: Iac4aa96a4963cbc33688c252e958a572c5c3b511
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46187
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When it is and isn't safe to assume an X509 field is non-NULL seems to
cause some confusion. (I often get requests to add NULL checks when
rewriting calling code.)
X.509 has surprisingly few optional fields, and we generally say
pointers are non-NULL unless documented. But that only works if we
remember to mention the nullable ones.
Change-Id: I18b57a17c9d57c377ea2227347e423f574389818
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46185
Reviewed-by: Adam Langley <agl@google.com>
We already know all the supported curves in runner.go. No sense in
repeating this list in more places than needed. (I'm about to need a
similar construct for -signing-prefs, so I figure it's worth being
consistent.)
This CL also adds a ShimConfig option because others don't support the
same curves we do and will likely run into this quickly.
Change-Id: Id79cea16891802af021b53a33ffd811a5d51c4ae
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46186
Reviewed-by: Adam Langley <agl@google.com>
The representation here is a bit more messy than necessary. In doing so,
clean up the variable names and smooth away two rough edges:
- X509_ALGOR_get0 would leave *out_param_value uninitialized if
*out_param_type is V_ASN1_UNDEF. Instead, set it to NULL, so callers
do not accidentally use an uninitialized pointer.
- X509_PUBKEY_set0_param, if key is NULL, would leave the key alone. No
one calls this function externally and none of the (since removed)
callers in OpenSSL rely on this behavior. A NULL check here adds a
discontinuity at the empty string that seems unnecessary here:
changing the algorithm without changing the key isn't useful.
(Note the API doesn't support changing the key without the algorithm.)
Note for reviewing: the representation of ASN1_TYPE is specified
somewhat indirectly. ASN1_TYPE uses the ASN1_ANY ASN1_ITEM, which has
utype V_ASN1_ANY. Then you look at asn1_d2i_ex_primitive and asn1_ex_c2i
which peel off the ASN1_TYPE layer and parse directly into the value
field, with a fixup for NULL. Hopefully we can rework this someday...
Change-Id: I628c4e20f8ea2fd036132242337f4dcac5ba5015
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46165
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In order to provide evidence to auditors that high-level functions end
up calling into the FIPS module, provide counters that allow for such
monitoring.
Change-Id: I55d45299f3050bf58077715ffa280210db156116
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46124
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
ASN1_OBJECTs are awkward. Sometimes they are static, when returned from
OBJ_nid2obj, and sometimes they are dynamic, when parsed from
crypto/asn1.
Most structures in crypto/asn1 need to support unknown OIDs and thus
must own their ASN1_OBJECTs. But they also may be initialized with
static ones in various APIs, such as X509_ALGOR_set0. To make that work,
ASN1_OBJECT_free detects static ASN1_OBJECTs and is a no-op.
Functions like X509_ALGOR_set0 take ownership, so OpenSSL has them take
a non-const ASN1_OBJECT*. To match, OBJ_nid2obj then returns a non-const
ASN1_OBJECT*, to signal that it is freeable.
However, this means OBJ_nid2obj's mutability doesn't match its return
type. In the fork, we switched OBJ_nid2obj to return const. But, in
doing so, we had to make X509_ALGOR_set0 and X509_PUBKEY_set0_param take
const ASN1_OBJECT, even though they would actually take ownership of
dynamic ASN1_OBJECTs. There are also a few internal casts with a TODO to
be const-correct.
Neither situation is ideal. (Perhaps a more sound model would be to copy
static ASN1_OBJECTs before putting them in most structs. But that would
not match current usage.) But I think aligning with OpenSSL is the
lesser evil here, since it avoids misleading set0 functions. Managing
ownership of ASN1_OBJECTs is much more common than mutating them. To
that end, I've added a note that ASN1_OBJECTs you didn't create must be
assumed immutable[*].
Update-Note: The change to OBJ_nid2obj should be compatible. The changes
to X509_PUBKEY_set0_param and X509_ALGOR_set0 may require fixing some
pointer types.
[*] This is *almost* honored by all of our functions. The exception is
c2i_ASN1_OBJECT, which instead checks the DYNAMIC flag as part of the
object reuse business. This would come up if we ever embedded
ASN1_OBJECTs directly in structs.
Change-Id: I1e6c700645c12b43323dd3887adb74e795c285b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46164
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This flag causes the runner to execute the shim with the RR debugger.
See https://rr-project.org/.
Unlike typical debuggers, the RR workflow is to first record a session
and then replay it. The user cannot interact with the debugger while
recording and they replay the session multiple times. For these reasons,
I've opted not to launch xterm like -gdb and -lldb do.
The other difference is that -rr-record restricts the runner to exactly
one test. Otherwise, it's too easy to accumulate a bunch of unwanted
recordings. Also, `rr replay` uses the most recent recording by default,
so it's not very useful for runner to record multiple tests.
Change-Id: I2d29d64df5c4c832e50833325db3500ec2698e76
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46144
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This will also pull in POLICY_MAPPINGS by way of STACK_OF(T) handling.
Change-Id: I8ddc9547647f8cae3800047eb58e1c83f6ae1085
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46104
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This is to help with cryptography.io compatibility. We don't implement
any of the flags (PKCS7_sign checks flags == PKCS7_DETACHED), but
cryptography.io now depends on the constant and PKCS7_SIGNER_INFO type
being available.
(cryptography.io also wants some new functions, but I think it's easier
to stub those out externally for now. If we need to actually enable
those features, we can look at actually implementing more of
PKCS7_sign.)
Change-Id: Id8419e34a68c04d4894417c7d6b13c1952d0bb88
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46084
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
OpenSSL classified their behavior as a bug and are fixing it for the
next release. In principle it'd be more compatible to emulate OpenSSL's
bug and undo it when we update OPENSSL_VERSION_NUMBER, but use of
PKCS12_parse is rare and this behavior is confusing, so let's leave it
as-is.
Bug: 250
Change-Id: I5f9825490a8afde67272dfaf476b35dbde94b59c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46064
Reviewed-by: Adam Langley <agl@google.com>
We aim to eventually make the entire X509 structure opaque, but let's
start small.
Update-Note: I believe this is now safe to do. If there are compile
failures, switch to X509_get0_notBefore, X509_getm_notBefore, and
X509_set1_notBefore, or revert this if I'm wrong and too many callers
still need updating.
Change-Id: I6e9d91630a10ac777e13ebcdeb543b3cbeea6383
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45965
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
PKCS#12 is overly general and, among other things, supports disabling
encryption. In practice, the unencrypted form is not widely implemented.
Moreover, even in contexts where cleartext is fine, an unencrypted
PKCS#12 file still requires a password for the mandatory MAC component.
They're not very useful.
However, cryptography.io uses them. Previously, we added support for
parsing these. This CL adds support for creating them too, because now
cryptography.io now also depends on that.
Change-Id: Ib7c4e29615047b6c73f887fea7c80f8844999bb7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46045
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
pkcs12_test.cc was getting a bit long. Along the way, embed_test_data.go
needed a fix to work around a syntax quirk of C++.
Change-Id: Ic4a19f77d177ebd607918feb253a08f1f9037981
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46044
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-Note: This removes a function that appears to be unused. It also
hardcodes the use of MD5, so please do not use it.
Change-Id: I67909c6360e4737fc22742592f88b907eb818e96
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45964
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I got the values flipped around. Also cryptography.io wants
EC_GROUP_get_asn1_flag to check a curve's encoding. We (mostly) only
support named curves, so just return OPENSSL_EC_NAMED_CURVE.
Change-Id: I544e76b7380ecd8dceb1df3db4dd4cf5cb322352
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46024
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This improves compatibility with cryptography.io. cryptography.io
doesn't actually care what we return, since the code won't run, but
feigning success seems better than failure. If some application does try
to run this function and checks, returning an error will probably crash
it.
Change-Id: I7a8164753a2f1a7b31dbeb10c7030c5e5fea2bc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46004
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Per RFC5280, section 5.1.1.2,
[signatureAlgorithm] MUST contain the same algorithm identifier as the
signature field in the sequence tbsCertList (Section 5.1.2.2).
This aligns with a check we already do on the X.509 side.
Update-Note: Invalid CRLs with inconsistent inner and outer signature
algorithms will now be rejected.
Change-Id: I9ef495a9b26779399c932903871391aacd8f2618
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45946
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This may as well be computed from block_size. This reduces the
per-EVP_CIPHER_CTX memory usage slightly.
Update-Note: It doesn't look like anyone is reading into this field. If
they are, we can ideally fix it, or revert this if absolutely necessary.
Change-Id: Ieef9177bed1671efca23d4f94d3d528f82568fc6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45884
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Get the up_ref functions and signature accessors.
Change-Id: Ie12e3a48ccc7e4c165ba08001232f5453e3dca11
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45945
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The X509 version APIs confuse everyone, including our own tests
(v3name_test.cc was using the wrong value). Introduce constants. Also
document which version to use for each type. It is extra confusing that,
although certificates and CRLs use the same Version enum, RFC5280
defines X.509 v3 certificates with X.509 v2 CRLs. (There are no v3
CRLs.)
I'll send a similar patch to OpenSSL to keep upstream aligned.
Change-Id: If096138eb004156d43df87a6d74f695b04f67480
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45944
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is a no-op, but relying on ASN1_INTEGER_get's internal handling of
NULL is confusing.
Change-Id: I49ab38c170d2f39fd3a4780b8c44b103a2ba4615
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45924
Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I85f0364b83440469c0d15c32dd96607be31fc1b7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45904
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
There are a few places where it is useful to run ECDSA with a specified
nonce:
- An ECDSA KAT in the module self-check
- Unit tests for particular test vectors
- Fuzzing the implementation (requested by the cryptofuzz project)
This replaces the fixed_k machinery with a separate function. Although
they are effectively the same, I've used two different functions.
One is internal and only used in the module self-check. The other is
exported for unit tests and cryptofuzz but marked with a for_testing.
(Chromium's presubmits flag uses of "for_testing" functions outside of
unit tests. The KAT version isn't in a test per se, so it's a separate
function.)
Bug: 391
Change-Id: I0f764d89bf0ac2081307e1079623d508fb0f2df7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45867
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The extra computation in the "setup" half is a remnant of
ECDSA_sign_setup, which was designed to amortize the message-independent
portion of the signature. We don't care about this amortization, but we
do want some control over k for testing. Instead, have ecdsa_sign_impl
take k and do the rest.
In doing so, this lets us compute m and kinv slightly later, which means
fewer temporaries are needed.
Bug: 391
Change-Id: I398004a5388ce5b7e839db6c36edf8464643d16f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45866
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In FIPS mode, we maintain a lock in order to implement clearing DRBG
state on process shutdown. This lock serves two purposes:
1. It protects the linked list of all DRBG states, which needs to be
updated the first time a thread touches RAND_bytes, when a thread
exits, and on process exit.
2. It ensures threads alive during process shutdown do not accidentally
touch DRBGs after they are cleared, by way of taking a ton of read
locks in RAND_bytes across some potentially time-consuming points.
This means that when one of the rare events in (1) happens, it must
contend with the flurry of read locks in (2). Split these uses into two
locks. The second lock now only ever sees read locks until process
shutdown, and the first lock is only accessed in rare cases.
Change-Id: Ib856c7a3bb937bbfa5d08534031dbf4ed3315cab
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45844
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This mirrors a change on the C side. Sessions may store the master
secret (main secret as of draft-ietf-tls-rfc8446bis-01) in TLS 1.2 or
the resumption PSK in TLS 1.3, so giving it any description other than
plain 'secret' isn't even accurate.
(Doing this separately from the rfc8446bis names since it's a bit less
mechanical.)
Change-Id: Iaf2b72fe298f17eeb4f4957cfd78b0015c3a9d89
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45824
Reviewed-by: Adam Langley <agl@google.com>
This is a very very basic sanity check on k generation, but it helps
make sure we haven't *completely* disconnected the RNG.
Change-Id: If7ae5dd6be3d0866962cd966b8c1ed1cdedffb50
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45865
Reviewed-by: Adam Langley <agl@google.com>
Trusty requires its own trusted app to implement the ACVP modulewrapper
functionality for validation. Separate the frontend from the generic
functions that implement each algorithm.
Change-Id: I86802b66c627ce4f5b5ddd54555a386e8e993eed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45604
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Make sure the recent changes to the builders all work.
Change-Id: I0eca1b7732da29a14325673deeb031c8863b45b8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45724
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These are ultimately just the upstream tarballs, but it's one less
ad-hoc script to maintain.
Change-Id: Ia93a7a9d4944d482e4e4137587998790e8e59294
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45784
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Newer versions of CMake have some fix for default libraries on
Windows/ARM64. (Not sure exactly what version, but the latest CMake does
seem to work.)
While trying to update the others, it turns out my workstation no longer
makes CMake builds compatible with the builders. It's also tedious that
updating CMake requires making builds myself. Fortunately, Chrome infra
is maintains some packages of third-party software in CIPD.
However, they don't make Windows CMake builds (filed
https://crbug.com/1180257 to request them), and they're stuck on 3.13.x
(blocked on https://crbug.com/1176531).
So, this CL switches to CIPD for Mac/Linux, with the latest version they
have available. It sticks with the old method (uploading copies of
upstream's packages) for Windows and grabs the latest version. When both
of the bugs above are fixed, hopefully things will be more uniform.
Change-Id: I710091fc60594165738a893b2be73cdcef54dfe2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45764
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
In trying to figure out an ARM64 builder issue, I tried VS2019. That
didn't fix the ARM64 issue, but it did reveal that I ported over some of
the logic from Chromium wrong. For "new-style" paths, the toolchain
directory should be toolchain_data['path'], not the parent directory of
win_sdk.
(The latest VS2019 package in Chromium puts win_sdk a few directories
down from the toolchain root.)
This CL should be a no-op for now because all our current toolchains use
Chromium's "old-style" win_sdk-relative paths.
Change-Id: I8ad7784abb479d1ede3995a44433e57448e8debf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45744
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit 4251d0d3f6, except
that the reland dates have been updated to not be in the past.
Change-Id: I7812c0e36d87ed1e049ec0a7d92a23efec881a81
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45704
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
I've left libc++ and Android tools for now. libc++ is running into
https://crbug.com/1166707. I'm not sure what's wrong with the Android
tools. (CMAKE_LINKER isn't defined for some reason, but it's defined on
my machine.)
We'll also want to update the builders before the NDK anyway. The new
NDK now defaults to ANDROID_ARM_NEON=TRUE.
Change-Id: I1c0fbc3e26368c04d31464477a51e04209aec7ba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45544
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
While I'm here, rewrite it a bit to align more with our preferred style.
(No assignments in conditions, no need for NULL checks on free
functions.)
See also 64a1b940d2b640e5edf0feae90e81bbb6b4941e7 from upstream.
Change-Id: I99a122343541e89d5950888de2c708cfa3ec45e2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45686
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CVE-2021-23840
(Imported from upstream's 6a51b9e1d0cf0bf8515f7201b68fb0a3482b3dc1.)
This differs slightly from upstream's version:
- EVP_R_OUTPUT_WOULD_OVERFLOW didn't seem necessary when ERR_R_OVERFLOW
already exists. (Also since we use CIPHER_R_*, it wouldn't have helped
with compatibility anyway. Though there's probably something to be
said for us folding CIPHER_R_* back into EVP_R_*.)
- For simplicity, just check in_len + bl at the top, rather than trying
to predict the exact number of bytes written.
Update-Note: Passing extremely large input lengths into EVP_CipherUpdate
will now fail. Use EVP_AEAD instead, which is size_t-based and has more
explicit output bounds.
Change-Id: I31835c89dcdecb6b112828f57deb798dc7187db5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45685
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Update-Note: No one uses this function. It had a NULL dereference in
some error cases. See CVE-2021-23841.
Change-Id: Ie1cc97615ac8b674147715d7d62e62faf218ae65
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45684
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This fixes an issue in a99308f that caused Bazel builds to break during
the analysis phase.
Change-Id: Ib26e70a52730f04905c2b2f137674f297488ec4f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45665
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This lets the builders pass it in via gclient_vars. Once this lands,
I'll make the builders fill it in, at which point we can remove the
magic 'env' value and the logic in the recipe.
Change-Id: Idfc4db3e4cdecf62eacbb2925fd545e1a76b2c79
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45624
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Newer versions of Bazel use a different setting for the crosstool_top
flag, depending on the NDK toolchain in use. This change detects these
crosstools and builds them using Android flags.
Fixes: 180083900
Change-Id: I937d18e53d72b2911e1c472adbce65282d31885d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45564
Commit-Queue: Justin Paupore <jpaupore@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Dan McArdle
David Benjamin
Bradley Hess
Adam Langley
Adam Langley
Stephen Crane
Justin Paupore