6 ms·
Rustls is really cool. I came to it because one of my projects used a library that in turn (by default) used OpenSSL. After much tinkering and not getting OpenS
by weinzierl 6y ago
Rustls is really cool. I came to it because one of my projects used a library that in turn (by default) used OpenSSL. After much tinkering and not getting OpenSSL play well on that particular system I switched to Rustls and it worked out of the box and like a charm.
That being said and from what I understand Rustls is not a drop in replacement and it is not that easy for all Rust libraries which use TLS.
Which brings me to the point that I think a big leap forward for wider Rustls adoption in the Rust world itself would be to make it easily usable with all popular and widely used Rust libraries that depend on a TLS implementation.
What I would like to see is sort of a global (not per dependency)
features = ["rustls-tls"]
so that all libraries and their dependencies use Rustls automatically
and OpenSSL is completely out of the picture. I know that this is not on Rustls alone but
on the library writers too, but still it would be really cool to switch the TLS implementation
like that.
Then we could even dream to make Rustls the default and use OpenSSL (or one of its relatives) only if need be.
- querez 6y agoisn't what you're arguing for essentially to make Rustls (or at least its API) part of a Rust standard library, so that everyone's forced (or very highly encouraged) to use it instead of alternatives?
- est31 6y agoNot suggesting it should be done, but note that Go does r̵i̵g̵h̵t̵ ̵t̵h̵i̵s̵ exactly this. They also have world class crypto people on the language team.
- richardwhiuk 6y agoIn what sense does Go do this right?
- est31 6y agoIt does right this not, this right. It's accessible to every go program: https://golang.org/pkg/crypto/tls/ https://golang.org/pkg/crypto/tls/
- pitaj 6y agoI've never heard someone use right this, is that similar to exactly this or just this?
- richardwhiuk 6y agoYeah, I'd expect that to be phrased as "does this" - the right seems utterly superfluous at best, and very misleading. "Right this minute" is a common phrase, but "does right this" isn't (at least in UK English).
- est31 6y agoHmm seems you are right. I guess it's a german-ism that slipped into my english. The english analog to "macht genau das" is either "does exactly that" or "does just that". The literal translation I used "does right this" seems to have no use. So my bad, I'm sorry.
- richardwhiuk 6y agoNo problem :)
- varajelle 6y agoHttp and https is accessible to every Rust program as well. It just has to be opt-in in Cargo.toml
- hctaw 6y agoGo has to do this because they include https in the standard library. Rust defers that task to the ecosystem, so it doesn't have the same requirements.
- hda2 6y agoSeeing that HTTP/S is now just as fundamental as tcp and udp, perhaps Rust should also consider doing the same? Sure, leave the more complex HTTP apis to the ecosystem, but Rust should at least have some sort of basic HTTP support. I don't think you can get away with not treating HTTP as a first class citizen anymore. IMO, Go got this right.
- varajelle 6y agoRust has HTTP and HTTPS support. You just have to enable it in your Cargo.toml. The ecosystem is part of rust.
- hda2 6y agoTo you, perhaps, but I wholeheartedly disagree. Rust will have support only when it is included in the standard library.
- hctaw 6y agoIf you spend all day writing web servers and clients it might seem fundamental. Most of my code doesn't touch the network so I don't mind if I need the ecosystem to do it - I do that in C and C++ too. I think people are fairly apprehensive towards a bigger std because firstly, dependency management is almost trivial (C++ needs the kitchen sink in std because dependencies don't exist to the language, for example) so it's not that big of a deal, and secondly because a bigger std means a bigger commitment to APIs and maintenance by a relatively small group of maintainers for all eternity. At the level of the stack where it makes sense to use rust, it doesn't make sense to put HTTP in std. At least not like Go.
- hda2 6y ago
- deleted 6y ago[deleted]
- e12e 6y agoI think that if tcp[1] is in the stdlib, tls probably should be too. Maybe even ssh. I get there was a time when "listen to the network" meant plain text networking - but today, for a large subset of applications and libraries, not supporting tls is a bug. [1] https://doc.rust-lang.org/std/net/struct.TcpListener.html https://doc.rust-lang.org/std/net/struct.TcpListener.html
- ChrisSD 6y agoImplementing crypto is much much harder than simply providing abstractions over the OS' TCP/UDP APIs. Far better to let the experts do it.
- e12e 6y agoThat's not really an argument against having it in stdlib, though?
- ChrisSD 6y agoIt's much simpler to develop complex libraries outside of the stdlib. And given Rust's strong stability guarantees, it can't stabilize any APIs until they're finalized anyway. So development of new APIs often happens outside the stdlib and then if a third party library proves itself and can commit to a completely stable API then it might be uplifted into the stdlib, so long as there's a very strong case to do so. I should also add that most applications won't even be using the TCP/UDP primitives directly. They'll likely be using a third party library. Rust's stdlib is intentionally minimal and lacking a lot of higher level features that are practically necessary for many applications.
- baby 6y agoTls is part of Golang’s stdlib
- hctaw 6y agoI'm really not a fan of having a global TLS knob to turn in all Rust crates... that strikes me as heavy handed and inelegant. Why give a global configuration variable for something used by a tiny portion of crates? And what if a crate is incompatible with rustls? How do you express that with such a global knob in a sane way? It's the wrong abstraction too - this is handled better by dynamic linkage. Rust just doesn't have a great dynamic library story (a C API/ABI is not exactly what I'm talking about here). What you'd really want is a trait TLS { // ... } in some base tls crate and leave the implementation up to other crates. And any upstream dependency would require something like: pub fn initialize <T: TLS> (tls:T) { ... }
- richardwhiuk 6y agohttps://crates.io/crates/native-tls/0.2.7 https://crates.io/crates/native-tls/0.2.7 provides this for native TLS implementations (which is what hyper-tls uses). It's pretty bare bones though, because to expose things through that, all of the underlying implementations need to support it.
- swsieber 6y agoMany crates do this type of thing. I don't know how hard it would be to isolate this type of thing into its own crate.