CMake's language is rather fragile and unsound. For the most part, it is
a shell script with more parentheses. That is, it simply expands command
arguments into a list of strings and then evaluates it, complete with
shell-style differences between "${FOO}" and ${FOO}.
The if() command is special and internally also expands variables. That
is why things like if(FOO STREQUAL "BAR") work. CMake interprets "FOO"
as a variable if it can find a variable, or a string otherwise. In
addition to getting very confused on typos, it means that
if("${FOO}" STREQUAL "BAR") will double-expand, and it will do strange
things if BAR is a variable.
CMP0054 patches this (which we set by minimum version) so that if() only
expands if the token was unquoted. This fixes
if("${FOO}" STREQUAL "BAR"). However, if(${FOO} STREQUAL "BAR")
continues to double-expand FOO.
We had a mix of all three of FOO, ${FOO}, and "${FOO}". It's not clear
which is the canonical spelling at this point, but CMake own files
(mostly) use FOO, as do most of our lines, so I've standardized on that.
It's a little unsatisfying if we typo a variable, but I suppose ${FOO}
also silently ignores unset variables.
Bug: 423
Change-Id: Ib6baa27f4065eed159e8fb28820b71a0c99e0db0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48705
Reviewed-by: Adam Langley <agl@google.com>
Some JSON files have a header, but without a URL. Thus consider a block
that doesn't contain an algorithm to also be a header.
Change-Id: Ic35a827843e9d0169ba8398df69c46a5baeffb44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48605
Reviewed-by: David Benjamin <davidben@google.com>
This is a reland of 160a8891ae with go.mod
and go.sum fixed. This updates golang.org/x/crypto, adds the latest
golang.org/x/net as a direct dependency (it was previously an indirect
dependency via x/crypto), and cleans up stale entries from go.sum with
go mod tidy.
Original change's description:
> Add util/fetch_ech_config_list.go
>
> I wrote this tool to make it easier to test the ECH client against
> real-world servers with the bssl client tool. I found that manually
> extracting an ECHConfigList from a raw HTTPS record is unnecessarily
> painful.
>
> The tool queries DNS over UDP for HTTPS records. If it finds any HTTPS
> records in the response, it attempts to extract an ECHConfigList from
> the "ech" SvcParam. It can write each extracted ECHConfigList to a file
> in a given directory. Once the ECH client implementation lands, the bssl
> client tool should have a new flag that that takes the path to an
> ECHConfigList file.
>
> I am using golang.org/x/net/dns/dnsmessage to parse the DNS response. I
> recently added the |UnknownResource| type to this library to enable
> callers (like us) to extract the bytes of otherwise-unsupported records
> (like HTTPS). I updated the dependency with `go get -u golang.org/x/net`.
>
> Although the bssl client tool knows how to resolve the address of its
> "-connect" parameter, it is difficult to query HTTPS records in a
> platform-agnostic way. If we decide the bssl client should directly
> query HTTPS rather than leaning on fetch_ech_config_list.go, we should
> look into libresolv. Specifically, the |res_query| function enables the
> caller to query arbitrary record types. This may open its own can of
> cross-platform worms; macOS and Linux typically ship with different
> implementations and it is not available on Windows. For more info, see
> `man 3 resolver`.
>
> Bug: 275
> Change-Id: I705591658921f60a958164a18b68ffb697c2ea4b
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44104
> Reviewed-by: David Benjamin <davidben@google.com>
Bug: 275
Change-Id: I9571e96c7a2ad7e239d86a353929a4e556d71287
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48106
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit 160a8891ae.
Reason for revert: This broke go.sum on CI for some reason. Will fix
and reland.
Original change's description:
> Add util/fetch_ech_config_list.go
>
> I wrote this tool to make it easier to test the ECH client against
> real-world servers with the bssl client tool. I found that manually
> extracting an ECHConfigList from a raw HTTPS record is unnecessarily
> painful.
>
> The tool queries DNS over UDP for HTTPS records. If it finds any HTTPS
> records in the response, it attempts to extract an ECHConfigList from
> the "ech" SvcParam. It can write each extracted ECHConfigList to a file
> in a given directory. Once the ECH client implementation lands, the bssl
> client tool should have a new flag that that takes the path to an
> ECHConfigList file.
>
> I am using golang.org/x/net/dns/dnsmessage to parse the DNS response. I
> recently added the |UnknownResource| type to this library to enable
> callers (like us) to extract the bytes of otherwise-unsupported records
> (like HTTPS). I updated the dependency with `go get -u golang.org/x/net`.
>
> Although the bssl client tool knows how to resolve the address of its
> "-connect" parameter, it is difficult to query HTTPS records in a
> platform-agnostic way. If we decide the bssl client should directly
> query HTTPS rather than leaning on fetch_ech_config_list.go, we should
> look into libresolv. Specifically, the |res_query| function enables the
> caller to query arbitrary record types. This may open its own can of
> cross-platform worms; macOS and Linux typically ship with different
> implementations and it is not available on Windows. For more info, see
> `man 3 resolver`.
>
> Bug: 275
> Change-Id: I705591658921f60a958164a18b68ffb697c2ea4b
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44104
> Reviewed-by: David Benjamin <davidben@google.com>
TBR=davidben@google.com,dmcardle@google.com
Change-Id: Iec36265dfa3b7c59eb811ed708219bfebb07a710
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 275
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48105
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I wrote this tool to make it easier to test the ECH client against
real-world servers with the bssl client tool. I found that manually
extracting an ECHConfigList from a raw HTTPS record is unnecessarily
painful.
The tool queries DNS over UDP for HTTPS records. If it finds any HTTPS
records in the response, it attempts to extract an ECHConfigList from
the "ech" SvcParam. It can write each extracted ECHConfigList to a file
in a given directory. Once the ECH client implementation lands, the bssl
client tool should have a new flag that that takes the path to an
ECHConfigList file.
I am using golang.org/x/net/dns/dnsmessage to parse the DNS response. I
recently added the |UnknownResource| type to this library to enable
callers (like us) to extract the bytes of otherwise-unsupported records
(like HTTPS). I updated the dependency with `go get -u golang.org/x/net`.
Although the bssl client tool knows how to resolve the address of its
"-connect" parameter, it is difficult to query HTTPS records in a
platform-agnostic way. If we decide the bssl client should directly
query HTTPS rather than leaning on fetch_ech_config_list.go, we should
look into libresolv. Specifically, the |res_query| function enables the
caller to query arbitrary record types. This may open its own can of
cross-platform worms; macOS and Linux typically ship with different
implementations and it is not available on Windows. For more info, see
`man 3 resolver`.
Bug: 275
Change-Id: I705591658921f60a958164a18b68ffb697c2ea4b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44104
Reviewed-by: David Benjamin <davidben@google.com>
NIST breaks these URLs so often it's unclear if it's worth including
them. If they do it again it might be a signal to remove them all.
However, until then, this change updates many of them. Some were deleted
because the format of the anchors has been switched and all the section
numbers remove, and I don't think it's worth trying to unpick all that.
Change-Id: I31457c225e68ee44d383a5a148fdcc80a3430864
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47464
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
In cases where the RPC from acvptool to modulewrapper is expensive,
these iterated tests take excessive amounts of time. By moving the
inner loop into the module wrapper the number of round-trips is reduced
by 1000×.
Change-Id: Ic047db071239492e416a08cab60d6a7e2905e8dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
When updating the test file for SHA-1 support, I forgot to remove the
non-deterministic bits (i.e. key and signature generation) from the
input vectors.
Change-Id: Id47f9b2cc85282f68b71aedc271d4b4b53e04c70
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47285
Reviewed-by: David Benjamin <davidben@google.com>
Clang 12 in opt mode produces a couple of assembly patterns that were
not handled by delocate.
Firstly, two-digit vector indexes were just a simple omission. Fixed.
Secondly, Clang puts symbol deltas in .byte directives, and bit-shifts
them. The .byte directive was not considered to be a symbol-containing
directive because it's too small, but it could store deltas.
Additionally, bit-shifting of symbol expressions was not supported.
Fixed.
Change-Id: I796299821f5ac7d3639fa6243c5d9bd5342bbddf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47064
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Change-Id: Ieb403b6651d445948abef48d7432fd248294284f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47084
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
They still need to be Python-2-compatible until I figure out how to
switch the version used in the CI.
I've left out make_curve25519_tables.py because it's some bytes vs
unicode mess I don't care to figure out. We should just rewrite that in
Go which should also be much faster anyway.
Change-Id: I4446641815315a84c2979b1be1e1949f88cbacf8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46884
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's defined as GCM without a plaintext input, so this is trivial.
Change-Id: Id430e998447e489c2bf2dd5c6541877870104ade
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46844
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: Ib2356f1a6e6ef8bfd5b5469eae9d1bc43dd40895
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46724
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
When doing Android FIPS validations one ends up with quite a lot of
different build configurations for ACVP and it's useful to be able to
check that a binary is what you think it is.
Change-Id: Ie5c81f164e6e6903c85ea832a93868f84921e74a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46484
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
GCC 4.9.0 was released April 2014, which was well over five years ago.
Change-Id: Ib26d459ed82a7af671b8524a334a6f99eacb003e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46346
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
To make the script run with python3, let me replace python2 specific
dict functions to python3 compatible ones.
Change-Id: I85b446234f9a86a02f60eed311e1c747a3ff399b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46364
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
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>
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>
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>
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>
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>
Sometimes JSON vector files contain a header element that must be
duplicated into the output and sometimes they don't. Auto-detect this by
looking for a “url” field in the first element.
Change-Id: I76046adb8ea64fe5ac9bae9d6583546504723918
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45524
Reviewed-by: David Benjamin <davidben@google.com>
CMAC-AES isn't inside our FIPS module, it's only included in
modulewrapper in order to test acvptool. Mark it with a special tag to
avoid it appearing when dumping regcap JSON because NIST paperwork is
such that it's better not to ACVP test such code.
Change-Id: I0c6d3a38bce9bf5766b889677eb3f7de94262c24
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45465
Reviewed-by: David Benjamin <davidben@google.com>
This is only used for testing acvptool but, yea, |memcmp| doesn't return
a bool 😳
This wasn't noticed because "ver" mode was missing from the registration
and thus from the test vectors.
Change-Id: I181c9b66aea4032543d39ebcc8728a01e0f34f55
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45464
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
test_fips probably needs to exercise everything that we have self-tests
for.
(The following change will eliminate the duplication of the code to
create the FFDH group. For reasons, that can't be done in this change.)
Change-Id: Ia72064db77381e7cf396a34b4723b2607f26f00b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45404
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
CMAC is not inside our FIPS module and we have ACVP support for it just
for testing (other modules need to validate CMAC). This change makes the
CMAC verify test an explicit action for the module wrapper so that a
verification function exposed by a FIPS module can be tested.
Change-Id: I3943bde175f2c1d62881002b4e12d7bca68a9018
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45264
Reviewed-by: David Benjamin <davidben@google.com>
GCC 10.2.1 seems to be emitting code like this:
movq gcm_gmult_clmul@GOTPCREL(%rip), %xmm0
movhps gcm_ghash_clmul@GOTPCREL(%rip), %xmm0
movaps %xmm0, (%rsp)
This is assembling a pair of function pointers in %xmm0 and writing the
two out together. I've not observed the compiler output movlps, but
supporting movhps and movlps are about as tricky. The main complication
is that these instructions preserve the unwritten half of the
destination, and they do not support register sources, only memory.
This CL supports them by loading in a general-purpose register as we
usually do, pushing the register on the stack, and then running the
instruction on (%rsp). Some alternatives I considered:
- Save/restore a temporary XMM register and then use MOVHLPS and
MOVLHPS. This would work but require another saveRegister-like
wrapper.
- Take advantage of loadFromGOT ending in a memory mov and swap out
the final instruction. This would be more efficient, but we downgrade
GOT-based accesses to local symbols to a plain LEA. The compiler will
only do this when we write a pair of function pointers in a row, so
trying to optimize the non-local symbols seems not worth the trouble.
(Really the compiler should not be emitting GOT-relative loads at all,
but the compiler doesn't know these symbols will be private and in the
same module, so it has a habit of pessimally using GOT-based loads.)
This option seemed the simplest.
Change-Id: I8c4915a6a0d72aa4c5f4d581081b99b3a6ab64c2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45244
Reviewed-by: Adam Langley <agl@google.com>
This invovles a |2048|^|225| modexp, which is far from ideal, but is now
required in FIPS mode.
Change-Id: Id7384b4ba92aa74e971231bc44fa0f10434d18e2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45085
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Revision 1.0 is this test is reportedly no longer acceptable and we have
to use the “SSC” version now. The documentation for this test doesn't
mention that a “z” field is possible, but that's what the test vectors
from the demo server contain and, after guessing at the correct response
format, this makes the NIST server happy.
Change-Id: Ic63d9e19998dc015733d847cd0330a3af1d5e7e6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45224
Reviewed-by: David Benjamin <davidben@google.com>
NIST currently seems to have a bug where they don't respect the regcap
for AES-CTR and return fractional-byte tests when not allowed.
Previously we didn't notice that the specified payload length didn't
match the actual value.
Change-Id: I0e48d5246f7250e6047d983cd016b0de290d0f70
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45205
Reviewed-by: David Benjamin <davidben@google.com>
The NIST production server doesn't like this.
Change-Id: I22ce31e822107f176eb97f7632ea2777c6ab4a44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45184
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
David Benjamin
Adam Langley
Dan McArdle
Piotr Sikora
Gurleen Grewal
Yoshisato Yanagisawa
Stephen Crane
Justin Paupore