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

Use rustls as an TLS engine #199

Open
3 of 4 tasks
sagebind opened this issue Jun 13, 2020 · 9 comments
Open
3 of 4 tasks

Use rustls as an TLS engine #199

sagebind opened this issue Jun 13, 2020 · 9 comments
Labels
breaking Requires breaking backwards compatibility feature A new feature!
Milestone

Comments

@sagebind
Copy link
Owner

sagebind commented Jun 13, 2020

Offer rustls as an optional TLS engine. The default behavior will remain to use the system-native TLS engine, but users should be able to opt-in to using rustls just with crate features.

Remaining work:

@sagebind sagebind added feature A new feature! blocked upstream Caused by an upstream dependency labels Jun 13, 2020
@xy137
Copy link

xy137 commented Sep 25, 2020

has there been any progress on this?

@sagebind
Copy link
Owner Author

Nope, not yet, but there's an upstream issue to add support for it in the curl crate here: alexcrichton/curl-rust#341

@suptejas
Copy link

suptejas commented Jan 6, 2022

Would really love this - this would make for a great performance improvement!

sagebind added a commit that referenced this issue Jan 8, 2022
Add the ability to opt-in to using rustls as the TLS engine for HTTPS requests with a `unstable-rustls-tls` crate feature.

Based on upstream work in alexcrichton/curl-rust#374.

See #199.
@sagebind sagebind removed the blocked label Jan 8, 2022
@sagebind
Copy link
Owner Author

sagebind commented Jan 8, 2022

The first step for this has at long last landed, as the upstream curl crate now has a rustls crate feature: alexcrichton/curl-rust#341.

Our work on Isahc's end is not finished though, as rustls does not use the operating system's trusted root certificates by default which is going to be an expected feature for Isahc (though potientially behind a separate crate feature). I'll keep the list of remaining tasks up-to-date in the issue description from here on out for more granular tracking.

In the meantime, you can now enable the unstable-rustls-tls crate feature on Isahc if you pull from the latest Git commit to start using rustls, though I expect there to be some rough edges at the moment.

@sagebind
Copy link
Owner Author

Adding "breaking" label to this, since the way Isahc 1.0 is configured, the native TLS engine is always enabled with no way of opting-out. We need to offer rustls and the native TLS engines as separate features that can be enabled or disabled, which is a breaking change.

2.0 is likely going to be a soon(ish) release anyway (a few months away probably) so seems like a good time to make rustls support part of that effort.

@sagebind sagebind added the breaking Requires breaking backwards compatibility label Mar 12, 2022
@sagebind sagebind removed the upstream Caused by an upstream dependency label Aug 6, 2022
@seanpianka
Copy link

Hello, is there a tracking issue for the 2.0 release? I am looking forward to seeing this feature-flag stabilized. Thanks!

@sagebind
Copy link
Owner Author

There is no tracking issue, but there's a milestone here: https://github.com/sagebind/isahc/milestone/13. There is no due date for version 2.0, it'll be ready when it is ready.

@lcmgh
Copy link

lcmgh commented Jun 22, 2023

Any update on this?

@sagebind
Copy link
Owner Author

sagebind commented Jun 23, 2023

@lcmgh Nope, sorry. I am currently taking a break from open-source work while I deal with some time-consuming projects in my personal life. It may be autumn this year before I can resume working on this. But thanks for your interest! I still plan on pushing this to the finish line, despite delays.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Requires breaking backwards compatibility feature A new feature!
Projects
None yet
Development

No branches or pull requests

5 participants