-
-
Notifications
You must be signed in to change notification settings - Fork 202
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
mbedtls implementation #211
Comments
How would you classify the set of targets that should use mbedtls? |
For our use case, we can use |
And OpenSSL will not build at all for espidf? |
We had partial bindings for openSSL but they were buggy and are being removed with esp-idf 5.0. There is a possibility we could extract the openSSL wrapper into its own library and maintain it separately. |
I'm just asking to confirm that making this change won't break people that were using OpenSSL on that OS already - if it's not supported at all then it should be fine to add mbedts for that case. |
Correct, it won't break any existing code by adding mbedtls support for espidf in this crate. I'll start working on a PR :). |
Any updates on this? :) @MabezDev |
@jan-br I have it working locally, but require some changes to mbedtls. Similar patches are in review upstream in mbedtls so I'm waiting for them to get merged, before I can open a PR here :). |
Thats great, thanks for your work @MabezDev . :) |
Both Xtensa and RISC-V will be supported :). |
Almost excellent timing. I also would like to use it for |
Hi again @MabezDev :) The ESP project I used as a template is the std demo project. Are all changes already upstream on those forks? Error after
|
Sorry not everything is pushed at the moment. The idea is to replace mbedtls-sys-auto completely with esp-idf-sys, but its been a bit tricky to work out all the issues thus far. Once I have something I can build I'll report back here. If you are desperate for tls however, just this weekend someone got the ring crate building on the espidf platform: briansmith/ring#1459, with an demo here: https://github.com/killyourphone/tlsdemo. There are still advantages to having mbedtls support (and rust-native-tls support) such as better use of the hardware peripherals for accelerated hashing etc, so I won't stop working on this but there is an alternative if you need something now :) |
Yeah TLS is an absolut hard requirement for my current project. So its been quite a blocker for a while now. |
Just saw this issue referenced from that PR after going to go check on it. Just be aware you'll have to deal with a lot of patched crates if you want to go with my ring/rustls setup, but it does work if you need something now. I also will make no guarantees of safety, stability, etc. I closely guard my ssh keys but I still never recommend people trust a stranger not to sneak something into one of your dependencies. I'm really hoping some of these changes get upstreamed so the list of crates to patch gets shorter. And of course as soon as this mbedtls work is done I think that'll be ideal for most use-cases. |
Yes I saw that. It is actually quite a mess, but I think I got ring working for now. |
@MabezDev are you still working on this? I recently got |
@MabezDev another poke ^^ |
Sorry for missing these! I'm not currently working mbedtls support but I did talk to a few colleagues internally about this. Instead of mbedtls we're probably going to wrap the esp-tls layer instead as the API surface is far smaller and in theory, allows us to use another TLS implementation underneath (WolfSSL is supported by esp-tls). I don't have any time scale on this sadly, this is currently a side project for the folks already maintaining esp-tls. For now, the best option is still to use the patched ring from esp-rs-compat. |
@Janrupf I would be very very interested in seeing how you implemented support for |
tokio-rs/mio#1602 - see here. TL;DR: I'm still working on a fully proper implementation (though CI is the main problem right now), but I already have a fully working mio for ESP32 implementation (and thus Tokio for ESP32) |
Fingers crossed for a successful merge upstream! Which reminds me that I should start the effort to upstream my own changes to |
Hi, |
really need this right now |
iirc it was working on the branch from my PR and the master of https://github.com/tiny-http/tiny-http (they didn't release a version with rust-native-tls support so far). Unfortunately there seems to be no interest in this change here |
I do realize it might not be a solution within the context of folks willing to reuse app-level Rust crates which are already hard-wired to |
Without
rust-native-tls
support, a lot of std crates become partially, or completely unusable. For our std target,riscv32imc-esp-espidf
, we have an mbedtls implementation available.rust-mbedtls
is a stable and well maintained crate with bindings to mbedtls. Would you be open to PR's adding support inrust-native-tls
?The text was updated successfully, but these errors were encountered: