Having our naming close to the standard makes things a bit clearer.
- ECDSA_SHA1_Legacy -> ECDSA_SHA1.
- RSA_PSS_SHA* -> RSA_PSS_RSAE_*.
- add RSA_PSS_PSS_* enums (not implemented on our side, but could be).
- ECDSA_NISTP* -> ECDSA_SECP*.
- complete supported_in_tls13(), in case these are encountered via
pluggable crypto.
This is a breaking API change.
The goal of this is to make it clear which parts
of the crate are specific to webpki, and which are intended
to be generic. Eventually, this gives a route to making
the `webpki` dependency optional, putting this module
(and callers of it) behind the `webpki` feature.
This is a breaking change.
These introduced an implicit dependency on the `webpki` crate
for anyone who wanted to implement these traits.
Instead, someone who wants to benefit from the `webpki`-backed
implementations should dispatch to `WebPkiServerVerifier` themselves.
Expose these defaults explicitly, and dispatch to them in our
various bits of example and test code.
This returned a slice of signature schemes allowed in TLS1.3.
But all callers actually needed something that would fit in
`Iterator::filter` so had to linear scan it.
Instead, move into a function on `SignatureScheme` (it's a fact about
that standard) and make it directly usable with `Iterator::filter`.
As pointed out by Jsha, an implementation of the `Acceptor` API may want
to create a verifier on something approaching a per-handshake basis in
order to provide up-to-date CRLs and client trust anchors.
We can improve on the cost of this operation by allowing shared use of
a `RootCertStore` across verifiers by wrapping it in an `Arc`.
This commit updates the `WebPkiClientVerifier`, and
`ClientCertVerifierBuilder` to take a `Arc<RootCertStore>` instead of
`RootCertStore`.
One side-effect of this change is the removal of the `add_roots` fn of
the `ClientCertVerifierBuilder` - once we take an `Arc` we can't modify
the backing `RootCertStore` without introducing some form of locking.
I think the use-case for adding additional `RootCertStore`'s after
constructing the builder is weak enough that we should drop that feature
rather than introduce locking.
In previous commits we reworked the primary implementation of the
`ClientCertVerifier` trait to be named `WebPkiClientVerifier`.
This commit updates the corresponding `ServerCertVerifier`
implementation in `WebPkiVerifier` to be named `WebPkiServerVerifier` to
match the client naming scheme and to better emphasize its role.
The `RootCertStore` type is used for both client and server trust
anchors. This commit renames the `add_server_trust_anchors` method to be
`add_trust_anchors` to reflect its general purpose.
Previously users configuring a `ServerConfig` that wanted to use
a webpki backed client certificate verifier had to make a choice of
which concrete implementation to construct, and how to configure it
(e.g. with trust anchors and CRLs). This made for a somewhat cumbersome
experience.
In its place, this commit:
* Adds a `WebPkiClientVerifier` type that replace both the
`AllowAnyAuthenticatedClient` and `AllowAnyAnonymousOrAuthenticatedClient`
verifiers. The name emphasizes that the implementation is backed by
`rustls/webpki` to help distinguish it from platform verifiers.
The new type can only be constructed external to the crate using
a `ClientCertVerifierBuilder` builder that walks the user through
specifying roots, CRLs, and policy for anonymous clients.
* Turns the `NoClientAuth` verifier into a crate internal type that also
only be constructed via the `ClientCertVerifierBuilder`.
* Removes the `boxed()` fn's of the above, since they won't be needed
anymore - consumers will construct a `Arc<dyn ClientCertVerifier>`
through the builder and don't need to have `ClientCertVerifier`
in-scope via the dangerous config feature.
* Updates all existing usages in tests and examples to use the new
builder API.
This commit resolves two TODO's left in `msgs/codec.rs` about using
`pub(crate)` visibility for `TlsListElement` and `ListLength` once MSRV
allows it. That time has come :)
Since v4 of the `actions/setup-go` action, caching is enabled by default
and when a `go.sum` can't be found in the root of the project, a warning
is logged.
Since we don't have a `go.sum` in the project root, this warning was
being issued by both tasks that used the `setup-go` action:
* The BoGo test suite task
* The code coverage task
For the first of these, caching is disabled to avoid the warning - we
weren't benefiting from this to begin with and setting
`cache-dependency-path` to `bogo/bogo/go.sum` or `bogo/go.sum` wasn't
working.
For the second of these, it's not clear _why_ we were installing the Go
toolchain. The BoGo test suite is not being run by this task and so Go
is not required. Removing it fixes the warning.
The `KeyExchange` trait's methods were ordered constructors -> complex
functions -> less complex functions. The original *ring* specific
`KeyExchange` didn't match this ordering. This commit synchronizes the
two.
This commit adds a `KeyExchange` associated type to the `CryptoProvider`
trait. The `KeyExchange` type is constrained with its own `KeyExchange`
trait that has an associated type for the `SupportedGroup`.
In the `crypto::ring` package we adapt the existing *ring* specific
`KeyExchange` and `SupportedKxGroup` types to these new traits.
Throughout the codebase we tighten generic bounds where required to
ensure we have a `CryptoProvider` bound that allows accessing the
associated `KeyExchange` and `SupportedGroup`. We also make the
`CryptoProvider` an associated type on the `Side` config.
This commit adds a trait for referring to supported key exchanges over
named groups in a general fashion. The *ring* specific
`SupportedKxGroup` type is then made to implement this trait.
This commit moves the existing Ring-based key exchange mechanisms from
`rustls/src/kx.rs` to `rustls/src/crypto/ring.rs` in anticipation of
adapting the codebase to a more general keyex trait that these types
will implement.
No changes are made to the implementation except to update import paths
to reference the new location.
The `KeyExchangeError` type is generic enough to live in the `crypto`
module. This will allow it to be shared with non-ring implementations in
the future.
For better code organization this commit moves the generic crypto
interface code from `src/crypto.rs` to `src/crypto/lib.rs`.
The *ring* specific code implementing the generic interfaces is moved to
`src/crypto/ring.rs` as a sub-module of `crypto. All imports are
adjusted accordingly.
This has the advantage of leaving `src/crypto/lib.rs` small, and without
any *ring* specific imports. In the future we may choose to feature-gate
the ring sub-module to allow building the crate without a dependency on
ring.
Following up on the previous commit, this commit updates the
`KeyExchange` struct's private `skxg`, `pubkey` and `privkey` fields to
be named `group`, `pub_key` and `priv_key`. This better matches the Rust
naming convention for struct members and makes for easier to understand
code.
The only consumers of the `pub(crate)` visible `pubkey` field of the
`KeyExchange` struct were using it to get at a `&[u8]` of public key
bytes.
This commit:
1. Unexports the `pubkey` field of the `KeyExchange` struct.
2. Adds a `pub(crate)` visible `pub_key()` method to return the public
key as a `&[u8]`.
3. Adjusts the tls12 client `emit_clientkx` function to use `&[u8]` for
its pub key argument.
4. Adjusts all callers to use the new `pub_key` accessor in place of the
field.
The name is changed from `pubkey` to `pub_key` to match Rust naming
conventions[0].
[0]: https://rust-lang.github.io/api-guidelines/naming.html
This commit adds some short guidance on performing maintenance point
releases when `main` has breaking changes, preventing using the normal
release process.
MSRV is important (an tested separately) for the core crate
(and its dependencies) but doesn't apply to test code.
Run these daily to notice any breakage earlier.
This commit updates the `build.yml` GitHub actions workflow to
additionally include a step that checks semver compatibility w/
cargo-semver-checks[0].
Notably this check passing is necessary but not sufficient for knowing
that we're maintaining semver: if this tool produces a finding we know
we aren't matching semver, but if it doesn't, we may still be breaking
semver in a way the tool can't detect.
[0]: https://github.com/obi1kenobi/cargo-semver-checks
Joseph Birr-Pixton
Daniel McCarney
Dirkjan Ochtman
Tshepang Mbambo
Jorge Aparicio
dependabot[bot]