Skip to content
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

feat(tls): upgrade to tokio-rustls 0.23 (rustls 0.20) #859

Merged
merged 2 commits into from
Jan 12, 2022

Conversation

djc
Copy link
Contributor

@djc djc commented Dec 6, 2021

No description provided.

@djc djc force-pushed the rustls-0.20 branch 5 times, most recently from 86ffa7b to 48ed610 Compare December 7, 2021 11:01
@LucioFranco
Copy link
Member

FYI this is will require a breaking release because we accept the client/server config from rustls in an api.

@LucioFranco LucioFranco added this to the 0.7 milestone Dec 7, 2021
Copy link
Member

@LucioFranco LucioFranco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for doing this!

@djc
Copy link
Contributor Author

djc commented Dec 8, 2021

What's the planning for 0.7? Would be nice not to carry around duplicate deps for this.

@djc
Copy link
Contributor Author

djc commented Dec 21, 2021

As discussed a bit on Discord, I added a commit that removes API surface referencing specific rustls types so that hopefully a future rustls upgrade won't need to be a semver-incompatible version bump.

Would still appreciate some context on planning for 0.7, since I'd like to make some changes to opentelemetry-stackdriver that would pull in rustls 0.20 -- but that crate also depends on tonic, and it would be nice not to depend on two versions of rustls/webpki.

@LucioFranco LucioFranco merged commit 4548997 into hyperium:master Jan 12, 2022
@tiziano88
Copy link

Is it still possible to pass in a custom rustls ClientConfig now?

@djc
Copy link
Contributor Author

djc commented Jan 14, 2022

No, it isn't. But we could potentially add API surface to ClientTlsConfig, depending on your use case?

@tiziano88
Copy link

Thanks, that would be great! We would definitely need this, we use a custom cert validator, and it seems after this commit there is no way of using it in tonic.

https://github.com/project-oak/oak/blob/a34217684954466983636ea09bb59c99759591e1/oak_client/src/attestation.rs#L122-L153

cc @ipetr0v @conradgrobler

@djc
Copy link
Contributor Author

djc commented Jan 14, 2022

Can you file a separate issue so we can be sure to track your use case? I have some ideas but will need to investigate in more detail.

@exFalso
Copy link

exFalso commented Feb 16, 2023

Hi, we're in the process of upgrading from tonic 0.6 to 0.8, and the direct rustls configuration seems to have been removed in this PR, and TLS configuration is now done completely differently. We'll try to update to the new way of configuring, but I think it'd be nice if there was still a way to configure rustls directly with a rustls::ClientConfig, as the new configuration options are quite limited and may not fit all use cases. Cheers!

@rollo-b2c2
Copy link

Bumping this. This is now a big blocker for us.

@LucioFranco
Copy link
Member

@exFalso @rollo-b2c2 the answer in this case is to use hyper directly, with rustls rather than going through tonics. Or using a custom acceptor/connector. We removed it from the public API so that we can upgrade it without making breaking releases.

@okjodom okjodom mentioned this pull request Oct 11, 2023
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants