In practice this test is more noisy than useful. This commit relaxes it
to only check that the builder types/intermediate states are debug, but
not that the debug representation is a byte-for-byte match to an
expected value.
The `HpkeSuite` type is small enough to be a candidate for `Copy`. The
`HpkePublicKey` type should be `Debug` and `Clone` so we can easily use
it for GREASE ECH configurations.
Fixes warnings generated with nightly when generating cargo docs of the
form:
```
error: unexpected `cfg` condition name: `bench`
--> rustls/src/lib.rs:305:31
|
305 | #![cfg_attr(not(any(read_buf, bench)), forbid(unstable_features))]
| ^^^^^
|
= help: consider using a Cargo feature instead or adding `println!("cargo::rustc-check-cfg=cfg(bench)");` to the top of the `build.rs`
= note: see <https://doc.rust-lang.org/nightly/cargo/reference/build-scripts.html#rustc-check-cfg> for more information about checking conditional configuration
```
We also need to apply this suggestion for `read_buf`, because of
a workaround documented for another upstream rust issue.
Note, because our MSRV is 1.63 we have to add the new `build.rs`
directives with the prefix `cargo:` instead of `cargo::` as described in
the warning output, or we get a new error of the form:
```
error: the `cargo::` syntax for build script output instructions was added in Rust 1.77.0, but the minimum supported Rust version of `rustls v0.23.5 (/home/daniel/Code/Rust/rustls/rustls)` is 1.63.
See https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script for more information about build script outputs.
```
When building with `--no-default-features --features ring` there are
a couple clippy warnings produced:
```
$ cargo check --manifest-path=rustls/Cargo.toml --no-default-features --features=ring
error: struct `Hmac` is never constructed
--> rustls/src/crypto/ring/hmac.rs:16:19
|
16 | pub(crate) struct Hmac(&'static ring_like::hmac::Algorithm);
| ^^^^
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]`
error: struct `Key` is never constructed
--> rustls/src/crypto/ring/hmac.rs:32:8
|
32 | struct Key(ring_like::hmac::Key);
| ^^^
```
This is fixed in this branch by conditionally compiling the
`crypto/ring/hmac.rs` mod based on whether we're building tests, or have
the tls-12 feature enabled.
In TLS1.2, this actually means ECDSA_SHA512. If the peer selects
that, we get caught out depending on the curve of the public key
because we don't support (for example) `ECDSA_NISTP256_SHA512`.
Reducing the preference of this improves matters, because a
peer that respects our priority will only select that if nothing
else is possible (which includes the cases that SHA256 and SHA384
are not supported, in which case we are hosed, but also if the
version is TLS1.3 and public key is on P521).
The macos-latest runner no longer comes with golang preinstalled.
Note that the fips build is not technically certified on macos,
but it is still nonetheless useful to defend the ability to
do `cargo test --all-features` on developer laptops.
We're seeing more of our deps move to this MSRV or higher (e.g.
`webpki`, `rustls-platform-verifier`) and it's shipped in Debian stable.
Time to move our MSRV to 1.63.
This allows callers to see if their handshake was Resumed,
Full, or Full-with-HelloRetryRequest (which, broadly, are the
three "cost" levels for handshakes).
This is exposed as soon as it is known for sure.
Rustls 0.23.2 added the groundwork for opting in to experimental
post-quantum key exchange support using `X25519Kyber768Draft00`.
Afterwards the remaining required pieces were released in a separate
crate, `rustls-post-quantum`. As a result this commit moves the
post-quantum KEX feature from the Future priorities to the Past
priorities.
This commit regenerates the test-ca PKI using the rcgen tooling.
A couple of small adjustments to unit tests are required:
1. We have to adjust down some expected write sizes: previously the
singular RSA chain had 2048, 3072 and 4096 bit keys and the larger
modulus sizes ensured a certain unit test always wrote more than 4000
bytes of data. With the new 2048 chain having _only_ 2048 bit keys
the expected write threshold needs to be adjusted down to 3000 bytes.
2. The expected subject common names expected in the client auth hint
tests need adjusting for the new RSA root common names.
3. We introduce new RSA_3072 and RSA_4096 key sizes, using the newly
generated test chains.
Otherwise all existing tests continue to pass as expected without
modification.
This commit updates the rustls crate's `examples/internal` module with
a new `test_ca` binary that generates the Rustls test PKI. It closely
matches the existing `build-a-pki.sh` script that generates the existing
test data, but does so in pure Rust using `rcgen`. It can be run with:
```
cargo run -p rustls --example test_ca
```
Unlike the existing script the RSA chain generation was switched to be
uniform with the approach used for ECDSA. Previously there was one RSA
chain with the EE/client certs using RSA 2048, the intermediate using
3072 and the root using 4096. This version instead uses the same key
size for all certs in the chain, but generates three chains: one for RSA
2048, one for 3072, and one for 4096.
The existing test-data is left as-is with this commit and will be
regenerated in a subsequent commit.
These aren't used anywhere and are just a byproduct of the OpenSSL based
generation script. We'll soon be rid of this script, so let's remove
these files.
This prepares for a change where we will generate RSA certificate
chains for three modulus sizes. The existing certificates are left
as-is, meaning the rsa-2048 intermediate and CA are using RSA 3072 and
4096 respectively. This will be fixed in subsequent commits with
a switch to new tooling.
This works around quality-of-implementation issues in OpenSSL and
Apple SecureTransport: they send `server_name` extensions containing
IP addresses. RFC6066 specifically disallows that.
It is a similar work-around to that adopted by LibreSSL: ignore
SNI contents if they can be parsed as an IP address.
This commit introduces a new `lock` module that exports a `Mutex`
wrapper type.
When the `std` feature is enabled the `Mutex` is a thin wrapper around
`std::sync::Mutex`. When the `std` feature is disabled, the user of the
library must provide a `Lock` implementation and a `MakeMutex`
implementation for producing instances of an appropriate lock.
`ServerSessionMemoryCache`, `ClientSessionStore`, `TicketSwitcher`, and
the aws-lc-rs/ring `Ticketer`s all rely on both a `HashMap`
implementation, and a `Mutex` implementation and so were gated as
requiring the `std` feature previously. With the `hashbrown` and
`crate::lock` module we can allow all of these items when either `std`
or the `hashbrown` features are enabled, supporting use in no-std
environments.
This commit introduces a new `hash_map` module that exports `HashMap`
and `Entry` types when the `std` or `hashbrown` feature are enabled.
The underlying types are provided from `std::collections` for the
former, and the optional `hashbrown` dependency for the latter.
`LimitedCache` and `ResolvesServerCertUsingSni` both relied on
a `HashMap` implementation, and so were gated as
requiring the `std` feature previously. With the `hashbrown` feature
we can allow both when either `std` or `hashbrown` features are enabled,
supporting their use in no-std environments.
Daniel McCarney
Joseph Birr-Pixton
Dirkjan Ochtman
MOZGIII
dependabot[bot]
Christian Poveda