0.24 tracking issue

[djc]

This is a tentative list of things considered for inclusion in the 0.24 release.

• reduce bifurcation of library internals by using low-level API in high-level API #1723
• Evolution of state machine representations #2397
• Consider a reader-writer split for the unbuffered API #2761
• Asynchronous calls to user-provided code #850
  • Poll-based encrypt/decrypt/sign API support in asynchronous and synchronous call #1976
  • Async code in ProducesTickets implementation #1808
  • Support asynchronous cryptographic accelerators under Linux #1033
• Consider a process default server certificate verifier #1821
• Evaluate whether CryptoProvider should become a trait #2401
• Consider implementing Drop for every public type #2446
• Allow in-place MessageEncrypter::encrypt #3068
• QUIC support for Acceptor #1218
• Make a builder for ClientConnections? #2850
• Review API impact of global/mutually exclusive features #2396
• Add kernel connection API #2370
• Convey client ALPN protocols in ClientConnection::new() instead of via ClientConfig #2260
• Audit public struct types for exhaustivity #2399
• Audit public enums for exhaustivity #2398
• export_keying_material() API doesn't conform with TLS 1.3 recommendations #945
• Review whether we should ship first-party crypto providers #2395
• Specify ciphersuites for TLS 1.2 and TLS 1.3 separately #1659
• Reinstate std feature/fix documentation #3134

API tweaks to make:

• FIPS: allow more detailed reporting of approval status #2309
• Pass ClientHello by reference to ResolvesServerCert #1908
• Clean up crate feature naming #1961
• Generalize error return from TicketSwitcher generator fn #2074
• Reevaluate additions to traits with default implementations #2119
• Reduce number of obsolete variants in CipherSuite enum #2171
• Drop PacketKey::*_for_path() default implementations #2315
• Consider dropping support for QUIC drafts #2378

[zh-jq-b]

How about #1876 and #1877 ?

[fenollp]

It seems this is missing from the list:

• Renamed feature logging to log: 192ab85
• Dropped feature aws_lc_rs: afa22bb
• Dropped provider from default features: 30f3753

Could 0.24.0-dev.0 be published? It'd help downstream dependents merge a few changes to main.
I'm not sure how the usual development cycle works.

EDIT: others are also in my place: rustls/tokio-rustls#118 ;)

[djc]

Why do you want to depend on rustls 0.24 now?

This is a tracking issue for work that we don't want to forget, not for work that is already done.

[ctz]

I think a prerelease may be a bit premature. For example, one outcome for #2395 could be withdrawing all crate features that control the built-in providers, and shipping that code as separate crates. If we go in that direction, it would waste work in the meantime to align upstream crate features with ours.

[fenollp]

I forked a few of my dependencies to be able to use

rustls/rustls/Cargo.toml

Line 17 in 8b96a51

default = ["log", "std"]

• Follow rustls@0.24 features changes seanmonstar/reqwest#2785
• Follow rustls@0.24 features changes tokio-rustls#119
• Follow rustls@0.24 features changes hyper-rustls#306
• Follow rustls@0.24 features changes rustls-platform-verifier#187

I'm not familiar in how development works in these repos, but I imagine no one would be happy having their main depend on a fixed rev nor on a third-party fork (mine). So I'm thinking, let's publish this

rustls/rustls/Cargo.toml

Line 3 in 8b96a51

version = "0.24.0-dev.0"

to crates-io. Not an actual release. And from there downstream consumers can make PRs and merge these new changes in their main branches. Then, when rustls publishes an actual 0.24 (or even an RC), downstreams can cut their own.

The minimal cut I'm asking for is this one: v/0.23.31...30f3753 although there may be more changes needed to make things work (this avoids 49 more commits).

In these forks I guess I could pin main instead of a specific rev, since all but hyper-rustls ship lockfiles. This would render my ask for a 0.24.0-dev.0 moot.

[djc]

@fenollp none of this makes much sense yet. main does not have substantial features or fixes that you couldn't get from 0.23.x releases, so I'll ask again -- what value are you getting from picking up the 0.24.x development branch?

I don't think we as maintainers want to make the extra effort to keep development branches alive and updated for all of these projects (at this relatively early stage of development of the 0.24.x release).

[fenollp]

Again, this is what my usage requires: 30f3753#diff-39675a2f0aded9ef531d4674b86b85702b904467031681533a6a0efc67085380R17
Without this change (and the forks) I am unable to drop aws-lc-rs from our codebase (in favor of ring).

WRT "keep[ing] development branches alive and updated for all of these projects":
I am suggesting to use main / master as a /single/ dev branch for the 4 repos mentioned. AIUI this is already a dev branch...

[djc]

It should definitely be possible to compile without aws-lc-rs even on current 0.23.x, which crate is unnecessarily activating the feature?

[fenollp]

Well it's hard for me to pinpoint with certainty :/ I do see that the versions of reqwest, sentry and rustls my crate directly depends on all have default-features = false and don't mention aws-lc-rs.
In my forks I did remove the aws feature from tokio-rustls's defaults', but left it in hyper-rustls's.
I'm forking crates because I couldn't find a way to disable features for a transitive dep ([patch] doesn't support that). Is there a way around that I missed?

So yeah, these forks are my only solution so far.

[ctz]

Well it's hard for me to pinpoint with certainty :/

cargo tree --invert rustls --edges features should tell you this. The output is all dependency paths that enable features on rustls.

[patch] should work; add a patch to a local fork of rustls which changes the crate's default features. Obviously there's a risk there that a dependency won't build because it expects the default features to provide items at rustls::crypto::aws_lc_rs but that should be something you could address with further patches.