[`git cherry-pick 4a39e2b67d4cddf58b0ea16dd821a04ee2240058`, with support
for Edition 2018 added by Brian.]
This commit introduces the Netflix BetterTLS[0]'s path building test
suite to the webpki integration tests.
This project has a test runner for Rustls that will stand up TLS servers
to exercise these tests but:
* It requires Go.
* It needs Rustls in order to do a full TLS handshake with the test
servers.
* It's slower than testing the path building directly without the TLS
bits.
To avoid these issues this commit takes a different approach and vendors
the exported path building test suite. This is a supported feature[1] of
the upstream project and allow us to directly test webpki's path
building against the test suite without needing Rustls or Go.
[0]: https://github.com/Netflix/bettertls
[1]: https://github.com/Netflix/bettertls#exporting-tests-to-run-outside-of-the-bettertls-executor
Cherry-picked from e473ee1ecb335d8efa3d4ceb2feb369f46b125f2 and modified
by Brian Smith. The main modifications were:
1. Maintain API compatibility with webpki 0.22.0.
2. (In `build_chain_inner`), stop immediately on fatal error, without
considering any more paths. The point of having such fatal errors
is to fail ASAP and avoid unneeded work in the failure case.
3. The test uses rcgen which requires Rust 1.67.0 or later. (I don't
think the non-test MSRV of webpki changes though.)
The original commit message is below:
Pathbuilding complexity can be quadratic, particularly when the set of
intermediates all have subjects matching a trust anchor. In these cases
we need to bound the number of expensive signature validation operations
that are performed to avoid a DoS on CPU usage.
This commit implements a simple maximum signature check limit inspired
by the approach taken in the Golang x509 package. No more than 100
signatures will be evaluated while pathbuilding. This limit works in
practice for Go when processing real world certificate chains and so
should be appropriate for our use case as well.
Reset the crate contents (sources, tests, etc.)
to what they were at that commit, while retaining the newer CI
configuration.
The changes since the 0.22.0 release were primarily intended to
accomplish two goals:
* Fix and improve the GitHub Actions configuration.
* Prepare a 0.21.5 release that was backward compatible with 0.21.4
but which also contained the improvements that were in 0.22.0.
0.21.5 was never released and will not be released. Therefore all
of the noise to facilitate the 0.21.5 release can just be deleted,
as long as we leave the CI changes that are necessary for GitHub
Actions to work correctly now.
The exact commands I used were:
```
git checkout \
6c334a2cf5 \
-- \
Cargo.toml \
LICENSE \
README.md \
src \
tests \
third-party
git rm src/trust_anchor_util.rs
```
Commit 6c334a2cf5 was the commit from
which 0.22.0 was released. It is confusing because the commit
immediately prior, 0b7cbf2d32, has
commit message "0.22.0". It appears that I merged the "0.22.0"
commit, expecting to `cargo publish` from that commit, but then
`cargo publish` failed. Then I added
6c334a2cf5 to fix `cargo publish`
and did the `cargo publish` from that commit. That's why I added
the `package` CI step at that time, to prevent this confusing
situation from happening again.
`trust_anchor_utils.rs` was not in 0.22.0; the `git checkout` didn't
delete it, so I had to do it separately.
I left the tests added subsequent to 0.22.0 in `tests/` (e.g.
`name_tests.rs`) since those tests pass with the 0.22.0 sources too.
Unfortunately, this requires disabling a bunch of Clippy lints, to
avoid modifying the contents from 0.22.0.
(I know it is confusing. It took me a while to figure it out myself
today.)
Only use *ring*'s `alloc` feature if webpki's `alloc` feature is enabled. This
disables RSA by default.
Adjust some tests that return different results depending on whether RSA is
available.
Test all feature configurations in CI.
Remove the `trust_anchor_utils` feature flag.
Guard all features that directly require allocation with a new `alloc` feature.
The RSA features will be handled separately.
Document the features. Tell docs.rs to document all features.
Adjust some tests so that tests are run in more configurations.
Brian Smith
Daniel McCarney
Fabio Valentini
Joseph Birr-Pixton
Jeffrey Griffin