We use the standard Apache 2.0 file header, described in "APPENDIX: How
to apply the Apache License to your work."
This was primarily automated by running:
git ls-tree -r --name-only HEAD | xargs go run ./util/relicense.go
See go/boringssl-relicensing-triage for the results of triaging the
output of the tool.
As part of this, switch from taking fiat-crypto under MIT license to
Apache 2.0. (It is licensed under MIT OR Apache-2.0 OR BSD-1-Clause.)
The copyright_summary tool can also be used to confirm we didn't
accidentally drop any copyright lines:
# Run before the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -out /tmp/old.json
# Run after the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -compare /tmp/old.json
Bug: 364634028
Change-Id: I17c50e761e9d077a1f92e25969e50ed35e320c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75852
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Matching the various pre-generated builds, the CMake build no longer
actually requires Go. The only things that need it are:
- Running tests
- Builds with -DFIPS=1
- Builds with the experimental symbol prefixing thing
Bug: 542
Change-Id: I52bb427f54dd6e5719cfe77773e87fc394410380
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67367
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This adds a tool for managing pre-generated files, aligning our CMake
and non-CMake builds. The plan is roughly:
The source of truth for the file lists will (eventually) be build.json.
This describes the build in terms of the files that we directly edit.
However, we have a two-phase build. First a pregeneration step
transforms some of the less convenient inputs into checked in files.
Notably perlasm files get expanded. This produces an equivalent JSON
structure with fewer inputs. The same tool then outputs that structure
into whatever build systems we want.
This initial version pre-generates err_data.c and perlasm files. I've
not wired up the various build formats, except for CMake (for the CMake
build to consume) and JSON (for generate_build_files.py to parse).
build.json is also, for now, only a subset of the build. Later changes
The upshot of all this is we no longer have a Perl build dependency!
Perl is now only needed when working on BoringSSL. It nearly removes the
Go one, but Go is still needed to run and (for now) build the tests.
To keep the generated files up-to-date, once this lands, I'll update our
CI to run `go run ./util/pregenerate -check` which asserts that all
generated files are correct. From there we can land the later changes in
this patch series that uses this more extensively. My eventual goal is
to replace generate_build_files.py altogether and the
"master-with-bazel" branch. Instead we'll just have sources.bzl,
sources.gni, etc. all checked into the tree directly. And then the
normal branch will just have both a CMake and Bazel build in it.
Update-Note: generate_build_files.py no longer generates assembly files
or err_data.c. Those are now checked into the tree directly.
Bug: 542
Change-Id: I71f5ff7417be811f8b7888b345279474e6b38ee9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67288
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The PATH-related workarounds for the old third-party Android toolchain
don't seem to apply to the official NDK one, so just remove them. The
official one does define the ANDROID variable, but only in an
"android-legacy.toolchain.cmake". I think the standard way to do this is
CMAKE_SYSTEM_NAME so switch to that.
Change-Id: I3f3fa69d482893c333ae06f54ac39434c3c6a56c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65670
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
sha512-armv8.pl and sha512-x86_64.pl implement both SHA-256 and SHA-512
and select which to emit by looking for "512" in the output path.
This can result in a false positive if the output path happens to
contain "512" in it. When the build uses relative paths, it's fine, but
this seems needlessly fragile. If we're generate into a temporary file,
there's a small but non-negligible probability that the path has a
"512" in it.
Instead, give those scripts three arguments: flavor hash output, so the
selection is independent of the output file name.
Bug: 542
Change-Id: Idf256abed1c07003034d3eb4544552125e3289e5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/62325
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
CMake and the generate builds now broadly share a source of truth for
the test files.
Update-Note: In the standalone CMake build, build/crypto/crypto_test is
now build/crypto_test, etc. For now, the build still copies the outputs
to the subdirectories (it's cheap and avoids some workflow turbulence),
but I'm thinking we keep that for six months or so and then remove it.
Bug: 542
Change-Id: I8f97e1fcedea1375d48567dfd2da01a6e66ec4e8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61286
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
If another project includes us as a subproject, as gRPC does,
CMAKE_SOURCE_DIR points to the top-level source directory, not ours.
PROJECT_SOURCE_DIR points to ours. Likewise, CMAKE_BINARY_DIR will
point to the top-level one.
gRPC doesn't consume this CMake build, but in preparation for
eventually unifying the two CMake builds, replace CMAKE_SOURCE_DIR and
CMAKE_BINARY_DIR with a combination of CMAKE_CURRENT_{SOURCE,BINARY}_DIR
and PROJECT_SOURCE_DIR.
There's one more CMAKE_SOURCE_DIR which controls some default install
directory. I've left that one alone for now as I'm not sure what to do
with it. Probably the answer is to, like in gRPC, disable the install
target by default when we're not the top-level source directory.
Bug: 542
Change-Id: Iea26bbef8a4637671fd0e7476101512e871e7e18
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57686
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We no longer have a need to support ppc64le, nor do we have any testing
story for the assembly we previously had. Remove all ppc64le-specific
assembly.
This CL stops short of removing it from base.h. That'll be done in a
follow-up CL, just to separate which removals are for the assembly and
which removals remove all support.
Update-Note: After this change, ppc64le builds drop assembly
optimizations and will fallback to a generic C-based AES implementation.
Change-Id: Ic8075638085761d66cebc276eb16c4770ce03920
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56388
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This follows up on
https://boringssl-review.googlesource.com/c/boringssl/+/55626, to make
the CMake build rely on the C preprocessor, rather than CMake. While not
as disasterous as pre-@platforms Bazel, CMake's build-level platform
selection is not ideal:
- CMAKE_SYSTEM_PROCESSOR is very inconsistent. There are multiple names
for the same architecture, and sometimes, e.g., building for 32-bit
Windows will still report "AMD64".
- On Apple platforms, there is a separate and technically multi-valued
CMAKE_OSX_ARCHITECTURES. We map that to CMAKE_SYSTEM_PROCESSOR, but
don't support the multi-value case.
Instead, broadly detect whether we expect gas or nasm, and then pull in
every matching file, relying on the C preprocessor to exclude files as
needed. This also fixes a quirk in generate_build_files.py, where it
needed to use the filename to detect the architecture of a perlasm
script in CMake.
This CL only applies to the standalone CMake build. The generated file
lists do not change. I'm not sure yet whether this strategy will be
appropriate for all those builds, so this starts with just the CMake
one.
This hits a pair of nuisances with the Apple linker. First, Apple has
two ways to invoke the linker. The new way is libtool, the old way is
ranlib. Warnings are different between the two.
In both libtool and ranlib, for x86_64 but not aarch64, we get a warning
about files with no symbols. This warning fires for us, but this change
makes it much, much noisier. Oddly, this warning does not trigger when
building for aarch64, just x86_64. I'm not sure whether this is because
aarch64 hits new behavior or it happens that aarch64 object files always
contain some dummy symbol.
libtool has a -no_warning_for_no_symbols flag to silence this warning.
Unfortunately, CMake uses ranlib and there is no way, from what I can
tell, to pass this flag to ranlib. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23551#note_1306698
Since this seems to be a broader CMake limitation, and we were already
living with some of these warnings, I've left this alone. But this CL
does make macOS x86_64 CMake builds very noisy.
I haven't used it here, but LLVM has a pile of CMake goo that switches
CMake to using libtool and passes in that flag. Trialing it out reveals
*different* issue, which I have worked around:
When invoked as libtool, but not as ranlib, the Apple linker also warns
when two object files have the same name. This appears to be a holdover
from static libraries using ar, even though ld does not actually invoke
ar. There appears to be no way to suppress this warning.
Though we don't use libtool, we can probably assume most non-CMake
builds will be using the modern spelling. So I've suffixed each perlasm
file with the OS. This means, in generate_build_files.py, we no longer
need a separate directory for each platform. For now, I've kept that
alone, because some update scripts rely on that spelling to delete old
files.
Update-Note: If the CMake build fails to build somewhere for an
assembly-related reasons, it's probably from this CL.
Bug: 542
Change-Id: Ieb5e64997dc5a676dc30973a220d19015c8e6120
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56305
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin