9bbf0d9763
This achieves much of the same goals as https://boringssl-review.googlesource.com/c/boringssl/+/61245, but reuses the existing source.cmake parser in generate_build_files.py. There are two practical differences here: First, CMake knows that, if it sees include(sources.cmake), it should add sources.cmake as a dependency of build.ninja, and re-run cmake if source.cmake changes. It does not know this for file(STRINGS). This can be fixed with CMAKE_CONFIGURE_DEPENDS, but since we already have this, may as well use it. Second, sources.cmake wants paths rooted at the top-level BoringSSL source directory, which means we want to define the targets at the top level, rather than in subdirectories. While it will make the top-level CMakeLists.txt larger, I think this is a good move: - ./build/crypto_test --gtest_filter=... is just less annoying to type than ./build/crypto/crypto_test --gtest_filter=... - It will (eventually) mean libcrypto.a lives at build/libcrypto.a instead of build/crypto/libcrypto.a. This means we can pass a single -L parameter when building things against BoringSSL, without relying on the install target. - It aligns with the generated CMake build. I would like, long-term, to stop maintaining multiple CMake builds, and the generated one seems to have a better convention. And one that will be more disruptive to others if we change it. - Top-level-rooted paths are more convenient for generate_build_files.py to work with, because that's what we want to output. As I get further along in 542, I expect I'll move this once again, possibly to some JSON file, because I'll need my new pregenerate tool to parse it (and we'll no longer be constrained by what's easy to consume in CMake), but use this for now. Bug: 542 Change-Id: I1e8b894057264da5d7624a1fbb92f9e1198ea38e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61266 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com>
BoringSSL pki - Web PKI Certificate path building and verification library
This directory and library should be considered experimental and should not be depended upon not to change without notice. You should not use this.
It contains an extracted and modified copy of chrome's certificate verifier core logic.
It is for the moment, intended to be synchronized from a checkout of chrome's head with the IMPORT script run in this directory. The eventual goal is to make both chrome and google3 consume this.
Current status:
- Some of the Path Builder tests depending on chrome testing classes and SavedUserData are disabled. These probably need either a mimicing SaveUserData class here, or be pulled out into chrome only.
- This contains a copy of der as bssl:der - a consideration for re-integrating with chromium. the encode_values part of der does not include the base::time or absl::time based stuff as they are not used within the library, this should probably be split out for chrome, or chrome's der could be modified (along with this one and eventually merged together) to not use base::time for encoding GeneralizedTimes, but rather use boringssl posix times as does the rest of this library.
- The Name Constraint limitation code is modified to remove clamped_math and mimic BoringSSL's overall limits - Some of the tests that test for specific edge cases for chrome's limits have been disabled. The tests need to be changed to reflect the overall limit, or ignored and we make name constraints subquadratic and stop caring about this.
- Fuzzer targets are not yet hooked up.