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>
These can replace the current der::Input-specific string_view methods. I
converted many of the uses within the library, but we should take a pass
over the library and turn many of the std::strings into
std::vector<uint8_t>.
On MSVC, we have to pass /Zc:__cplusplus for __cplusplus to be set
correctly. For now, I'm going to try just adding the flag, but if pki
gets used in more places before we bump our minimum to C++17, we may
want to start looking at _MSVC_LANG instead.
There are actually a few places outside of pki that could use this, but
we sadly can't use them until we require C++17 across the board.
Bug: 661
Change-Id: I1002d9f2e1e4a2592760e8938560894d42a9b58c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65908
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Matt Mueller <mattm@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Span/view types are small enough that the guidance these days is to pass
by value. This CL is the result of two sed lines:
sed -i -e 's/const Input &/Input /g' pki/*.*
sed -i -e 's/const der::Input &/der::Input /g' pki/*.*
Plus one manual fix inside a comment in pki/parser.h where the spacing
didn't match. Then a clang-format -i
Change-Id: I29c9ffc7ddf2df5822e5335f108c85ecbf496a3c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65669
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Matt Mueller <mattm@google.com>
This adds a bunch of methods from Span, with the end goal of eventually
making it into a typedef for Span<const uint8_t>. In doing so, this
makes Input implicitly convertible to Span<const uint8_t> and every
other span<const uint8_t> type. For the other direction, I've removed
the 'explicit' marker on the Input(Span) constructor.
I've kept the older spellings around to avoid forcing us to fix it all
at once, but after this rolls in to various places, the next things to
do would be:
1. Go through downstream code and switch them to using the span-like
spellings. Better yet, have them just pass to their own span type.
2. Since Input <-> Span converts implicitly, we can freely start making
our APIs take Span instead of Input. Also start cleaning up a bunch
of now unnecessary explicit der::Input(foo) calls now that, like
span, it's implicit.
3. Decide what to do with the char vs uint8_t disaster. I'm thinking we
add free functions to convert between the two.
In doing so, I've also switched some easy places to use more span-y
APIs.
Bug: 661
Change-Id: I731bb110a4fdadd99cb2894e48f016f0b19110ac
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65668
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Matt Mueller <mattm@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Initially this leaves the canonical source in chrome, Additions
and fillins are committed directly, the chrome files are coverted
using the IMPORT script run from the pki directory for the moment.
The intention here is to continue frequent automatic conversion
(and avoid wholesale cosmetic changes in here for now) until
chrome converts to use these files in place of it's versions.
At that point these will become the definiative files, and the
IMPORT script can be tossed out.
A middle step along the way will be to change google3's verify.cc
in third_party/chromium_certificate_verifier to use this instead
of it's own extracted copy.
Status (and what is not done yet) being roughly tracked in README.md
Bug: chromium:1322914
Change-Id: Ibdb5479bc68985fa61ce6b10f98f31f6b3a7cbdf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60285
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
David Benjamin