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>
Following the guidance in
https://opensource.google/documentation/reference/releasing/authors,
start maintaining an AUTHORS file.
Update all existing Google copyright lines to 'The BoringSSL Authors'
per the document. This CL also changes the styling to match the new
guidance: removed the '(c)' and the comma.
All other existing copyright lines are left unmodified. Going forward,
our preference will be that new contributions to BoringSSL use 'The
BoringSSL Authors', optionally adding to the AUTHORS file if the
contributor desires.
To avoid being presumptuous, this CL does *not* proactively list every
past contributor in the BoringSSL half of the AUTHORS file. Past
contributors are welcome to send us a patch to be added, or request that
we add you. (Listed or not, the commit log continues to be a more
accurate record, and any existing non-Google copyright lines were left
unmodified.)
The OpenSSL half of the AUTHORS file is seeded with the contents of the
current OpenSSL AUTHORS file, as of writing. The current contents in the
latest revision of the 1.1.1 branch
(b372b1f76450acdfed1e2301a39810146e28b02c) and master
(d992e8729ee38b082482dc010e090bb20d1c7bd5) are identical, just formatted
in text vs Markdown.
Note when reviewing: CONTRIBUTING.md and AUTHORS contain non-mechanical
changes.
Bug: 364634028
Change-Id: I319d0ee63ec021ad85e248e8e3304b9cf9566681
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74149
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Now that we can generate build files, we can actually maintain a Bazel
build in HEAD, without synthesizing a separate "-with-bazel" branch.
(Though we'll still need both for a transition, and until all the other
build modes have migrated.) Note this has a slightly different directory
structure than the old -with-bazel branch. But the targets are the same
and #include <openssl/whatever.h> still works, so hopefully it's
compatible.
For now, I'm only setting this up with the new bzlmod scheme. Also since
pulling in googletest is much less tedious with bzlmod, I've wired up
tests and everything.
https://bazel.build/external/overview#bzlmod
To build, run commands like:
bazelisk build ...
bazelisk test ...
bazelisk run :bssl
The thinking is we can also go add this to CI and whatnot.
This is also intended to replace the boringssl module in the
bazel-central-registry which someone else set up already. To ease the
transition, I've seeded the compatibility_level value with theirs. (I
think we want to never bump it. Although we don't do SemVer, I think
bzlmod's MVS version selection scheme is generally reasonable. Bumping
it just introduces hiccups into the update process where projects need
to coordinate updates, and we do not want that.)
I wasn't clear on what to put in the version field in the tree, so I
just went with 0.0.0-dev so we don't have to change it, but it's still
vaguely analogous to the versions already in there.
As part of this, I've added support for Bazel's runfiles mechanism in
crypto/test/test_data.cc. This is completely undocumented and I had to
figure out how it works by guessing, but I believe this is the
officially supported way to make cc_test(data = ...) work? The official
documentation says to use devtools_build::GetDataDependencyFilepath, but
that API does not exist in the first place. I've also made it build with
C++17 for now, so we can build libpki, but C++14 consumers should still
be able to use this module, just not build libpki.
To that end, one difference between this and the old module is that we
no longer specify the C++ version in the build. From what I can tell,
Bazel does *not* want libraries to set the C/C++ version and prefers it
only come from the root. Unfortunately, they provide zero tools to
effectively manage this. I've followed this pattern for C++ versions, as
we can assume that Bazel projects are very aware of their C++ version,
but I've explicitly ignored it for the C version. Projects tend not to
change ABIs by C version, so it should be fine to set it internally.
For context when reviewing, the unreadable MODULE.bazel.lock is
automatically generated. I think the idea is that subsequent diffs will
be more readable??
Bug: 542
Change-Id: I88f68b2602a75f58cc6d18832a956f01dc054f58
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/67301
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
David Benjamin