Prepare 0.23.0 #1817
Prepare 0.23.0 #1817
Conversation
Benchmark resultsInstruction countsSignificant differencesThere are no significant instruction count differences Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1817 +/- ##
=======================================
Coverage 95.83% 95.83%
=======================================
Files 84 84
Lines 18861 18861
=======================================
Hits 18075 18075
Misses 786 786 ☔ View full report in Codecov by Sentry. |
|
Note that I tried using |
|
Thanks! Here's some initial feedback (sorry, can't do a "real" review for PR description content).
I think we should explicitly call out that code that was using Edit: This also applies for
Worth mentioning this disables some functionality that will be restored in follow-up work?
Nit: I'd say "while sending data" instead of "during sending data"
Typo: "If a TLS alert ..."
We've received feedback in the past that it's helpful to point to examples. Maybe put a forward pointer here to the server acceptor example?
I think these are the same change? Could probably fold them both into one listing. |
Maybe worth mentioning a couple of the new reqs up front? I'm thinking the Windows nasm one in particular since I've had to update several Rustls CI configurations to add that on Windows. |
|
OK, I think I have addressed those comments. Thanks! |
|
Here are a few more items for consideration:
|
|
For stuff that landed in 0.21 releases, it doesn't seem very useful to call them out (assuming they were called out appropriately in the earlier releases) -- I think people would intuitively expect them to be part of this release anyway. I also agree with your parenthetical that the |
This evokes the question for a link to details on the "further build-time requirements", maybe just mention explicitly "as detailed in the FIPS documentation."?
I would probably omit the comma before "must now" but this maybe inviting some age-old discussion on the Oxford comma, not sure? Also "unambigious" -> "unambiguous" and not sure what is going on with the last sentence here, which isn't capitalized and ends with a stray
Would replace ", this is a default feature" with "A new (enabled by default)
Given the wider applicability, should this go before the other one?
|
|
Should we also call out the public availability of rustls-platform-verifier somehow? |
Done.
Addressed these points. The last sentence was a quote of the panic message: have blockquoted this to take it out of the flow of the text.
Have dropped the "future work" sentence & adapted the "work is ongoing" part.
Swapped. |
I guess I would suggest we use different (from |
I think this is functionally invisible really.
Added these (please review language).
I think these are in 0.22.1 or 0.22.2. |
Fair 👍
I vote no - there isn't a release of rustls-platform-verifier you could use with 0.23. I suspect based on how long it took to turn around previous releases that it will be a little bit before one is available. |
|
I did another read through of the proposed text and it looks good to me 👍 |
Release notes (proposed)
Default cryptography provider changed to
aws-lc-rs. Note that this has some implications on platform support and build-time tool requirements such ascmakeon all platforms andnasmon Windows.Support for
ringcontinues to be available: set theringcrate feature.Support for FIPS validated mode with
aws-lc-rs: see the manual section and aws-lc-rs's FIPS documentation. Note thataws-lc-rsin FIPS mode has further build-time requirements as detailed in the FIPS documentation.Support for process-wide selection of
CryptoProviders. See the documentation. Note that callers ofClientConfig::builder(),ServerConfig::builder(),WebPkiServerVerifier::builder()andWebPkiClientVerifier::builder()must now ensure that the crate's features are unambiguous or explicitly select a process-level provider usingCryptoProvider::install_default(). Otherwise, these calls will panic with:We recommend that libraries rely on the process-level provider by default, and that applications use this new API to select the provider they wish to use.
New unbuffered API.
UnbufferedClientConnectionandUnbufferedServerConnectionoffer a low-level, event-driven API which does not internally buffer data.Thanks to the team from Ferrous Systems.
New
no_stdsupport. A new (enabled by default)stdcrate feature now gates all APIs that depend onstd. The above unbuffered APIs must be used forno_stdsupport. Note thatalloccontinues to be required. Work is ongoing to reintroduce certain APIs forno_stdusers (see no-std support phase II #1688) -- please file issues for otherno_stduse cases.Thanks to the team from Ferrous Systems.
Performance improvement: internal copying while sending data is reduced.
Thanks to the team from the Sōzu project.
Performance improvement:
write_vectorednow produces less on-the-wire overhead, which will dramatically improve throughput if it is used with a large number of small messages.Thanks to the team from the Sōzu project.
AcceptorAPI error handling improvement. If a TLS alert should be sent to inform the peer of a connection failure, this is now made available in theErr()variant returned fromAcceptor::acceptandAccepted::into_connection(which is also a breaking change). Applications should write this data to the peer. See the server_acceptor example.Support for FFDHE key exchange: custom
CryptoProviderscan now support FFDHE key exchange, in accordance with RFC7919. Note that the default providers do not do this.Thanks to the team from Fortanix.
Support for servers requiring
extended_master_secretsupport from clients. SeeServerConfig::require_ems.Thanks to the team from Fortanix.
Extension ordering in ClientHello messages are now randomised as an anti-fingerprinting measure. We do not foresee any interoperability issues as Chrome has already rolled out the same change.
Thanks to @GomesGoncalo.
Breaking change:
CipherSuiteCommon::integrity_limitfield removed (this was QUIC-specific, it has moved toquic::PacketKey::integrity_limit()).Breaking change:
crypto::cipher::BorrowedPlainMessageandcrypto::cipher::OpaqueMessagehave been renamed (toOutboundPlainMessageandOutboundOpaqueMessage) and altered to support performance improvements. See the example code.Breaking change: all protocol enum types (eg.
CipherSuite) have had theirget_u8/get_u16accessor removed; useu8::from()/u16::from()instead.