-
Notifications
You must be signed in to change notification settings - Fork 100
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
(WIP — do not merge) Switch from native-tls to rustls #151
Conversation
This is an unfinished patch to switch `irc` from depending on [`tokio-tls`] and [`native-tls`], which @aatxe says "has caused a reasonable amount of annoyance", to [`tokio-rustls`] and (through it) [`rustls`]. This patch uses the 0.8.0-alpha version of `tokio-rustls`, which has a `tokio-tls`-esque API. Even if this patch were finished, it should not be applied until that `tokio-rustls` API fully is released. While `irc` compiles with this patch applied, the following work remains to be done: - Implement CertFP — `rustls` provides a less convenient API for client certificate authentication than does `native-tls`, and I (@8573) don't understand cryptographic APIs well enough to implement CertFP with it. This WIP version of my patch provides only a stub implementation of the necessary `rustls` trait, [`ResolvesClientCert`], which implementation will not actually provide any client certificate to `rustls`, even if one is specified in the `irc`-level client `Config`. - Run `irc`'s test suite with this patch applied. - Confirm that `irc`'s dependents still work with this patch applied. [`ResolvesClientCert`]: <https://docs.rs/rustls/0.13.1/rustls/trait.ResolvesClientCert.html> [`native-tls`]: <https://crates.io/crates/native-tls> [`rustls`]: <https://crates.io/crates/rustls> [`tokio-rustls`]: <https://crates.io/crates/tokio-rustls> [`tokio-tls`]: <https://crates.io/crates/tokio-tls>
I can run |
Note that |
As of Though making feature to choose between |
Just a note to clarify the "reasonable amount of annoyance" comment, it was directed mainly at OpenSSL which seems to break builds frequently, rather than |
@DoumanAsh Unless you're using |
Any news on this topic ? If needed, I will be happy to fill a PR for the RustTls support. I guess I will have to:
I can send all in one PR or split each task into a their own PR. |
@tirz: If you're familiar with the relevant cryptography, that sounds good to me. I certainly am unlikely to finish this work myself. |
I successfully implemented it on my fork: https://github.com/tirz/irc/tree/feature-ssl_backends Edit: I am just waiting for the proxy feature to be reviewed and then I will still have to implement a custom certificate selection for rustls. |
This is an unfinished patch to switch
irc
from depending ontokio-tls
andnative-tls
, which @aatxe says "has caused a reasonable amount of annoyance", totokio-rustls
and (through it)rustls
.This patch uses the 0.8.0-alpha version of
tokio-rustls
, which has atokio-tls
-esque API. Even if this patch were finished, it should not be applied until thattokio-rustls
API fully is released.While
irc
compiles with this patch applied, the following work remains to be done:Implement CertFP —
rustls
provides a less convenient API for client certificate authentication than doesnative-tls
, and I (@8573) don't understand cryptographic APIs well enough to implement CertFP with it. This WIP version of my patch provides only a stub implementation of the necessaryrustls
trait,ResolvesClientCert
, which implementation will not actually provide any client certificate torustls
, even if one is specified in theirc
-level clientConfig
.Run
irc
's test suite with this patch applied.Confirm that
irc
's dependents still work with this patch applied.