-
Notifications
You must be signed in to change notification settings - Fork 741
Prepare 0.23.24 #2383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare 0.23.24 #2383
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 #2383 +/- ##
=======================================
Coverage 96.16% 96.16%
=======================================
Files 94 94
Lines 22814 22814
=======================================
Hits 21939 21939
Misses 875 875 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I went through the commits since .23 and didn't spot anything that felt relevant that wasn't covered.
Users handling CertificateError variants individually should note the new variants, such as CertificateError::NotValidForNameContext (compare CertificateError::NotValidForName).
Is there more to say about the purpose of CertificateError::NotValidForName
now that the Context
variant exists? Is it retained for semver purposes only or can it still be emitted? It looks to me like the former but I only did a quick scan.
Behavior change: Clients no longer offer resumption between different ClientConfigs that share a resumption store ....
WDYT about using this as an opportunity to make a small note about how this should also be considered for reusing server configs with some of the text from #2381 ?
Added a note -- I think the answer is that all the previous variants remain both for semver reasons but also for non-webpki verifiers (eg, platform-verifier) which I expect will continue to use them.
Added a reference for this. |
ref rustls/rustls-platform-verifier#163
Proposed release notes:
New feature: More detailed and helpful error reporting for common certificate errors, such as name mismatches and certificate expiry. Users who
std::fmt::Display
the rustlsError
type will take advantage of this automatically. Users handlingCertificateError
variants individually should note the new variants, such asCertificateError::NotValidForNameContext
(compareCertificateError::NotValidForName
).The old
CertificateError
variants (such asNotValidForName
,Expired
, etc.) remain usable, and may be produced by both the default and third-party certificate verification traits.New feature: Allow KTLS handoff for unbuffered API users, by introducing
dangerous_extract_secrets()
. Thanks to @edef1c.Bug fix: Unbuffered connections now consume data during the
next_record()
function, rather than production of the state. This fixes unbuffered: No way to refuse a ReadTraffic if there is no space #2031.Bug fix: Build speed improvement for aws-lc-rs
fips
users.Behavior change: Clients no longer offer resumption between different
ClientConfig
s that share a resumption store but do not share server certificate verification and client authentication credentials. If you share a resumption store between multipleClientConfig
s, please ensure their server certificate verification and client authentication credentials are also shared. Please read the new documentation on theClientConfig::resumption
item for details.Additionally, if you share a resumption store or ticketer between multiple
ServerConfig
s, please see the new documentation onServerConfig
about this.