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.
This adds support for verification of ed25519 certificates according to
RFC 8410. Implements #49.
The test certificate was generated using OpenSSL 1.1.1a, using the
following commands (CA.pl is distributed with OpenSSL):
openssl genpkey -algorithm ed25519 -outform pem -out root_key.pem
openssl req -new -x509 -days 9999 -extensions v3_ca -key root_key.pem \
-inform pem -outform pem -out root_ed25519.pem
echo root_ed25519.pem | CA.pl -newca
openssl genpkey -algorithm ed25519 -outform pem -out client_key.pem
openssl req -new -key client_key.pem -inform pem -outform pem \
-out client_ed25519_csr.pem
openssl ca -keyfile ./root_key.pem -days 999 -notext -in \
client_ed25519_csr.pem -out client_ed25519.pem
I agree to license my contributions to each file under the terms given
at the top of each file I changed.
Simplify the way algorithm identifiers are parsed. Simplify the tests
to account for the new simpler parsing.
Simplify how algorithm identifiers are matched against known algorithm
identifiers by using just bytewise comparison.
Simplify the storage of known algorithm identifiers by including their
binary DER-encoded values from files in src/data/. Remove most of the
macros for encoding OID values as they are no longer needed. Remove the
script for generating PSS-related AlgorithmIdentifier parts in favor of
using der-ascii in the future, as documented in src/data/README.md.
Remove the encoded PSS parts generated from the deleted script, as they
were replaced in this transition.
Based on some research the Google Chrome team did, there's no strong
need to support rsaEncryption signatures where the NULL is missing
unless/until we add OCSP support.
This has tests generated by openssl, and integrated with
the existing chromium verify_signed_data corpus.
The PSS parameter encodings are slightly unwieldy, and
are included from files rather than embedded in the source.
There are python scripts for regenerating the parameter encodings
and tests.
This enables us to support exactly one OID per signature algorithm.
A Censys search found no publicly-trusted certificates using this OID:
https://censys.io/certificates?q=parsed.signature.signature_algorithm.oid%3A+1.3.14.3.2.29
This won't impact uses of RSA PKCS#1 SHA-1 for ServerKeyExchange
signatures since those signatures don't identify the algorithm using
OIDS.
Brian Smith
Daniel McCarney
Andy Russell
Sebastian Hahn
Joseph Birr-Pixton