Comment by weinzierl | Hacker News Reader

Comment by weinzierl | Hacker News Reader

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.

isn'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?

Not 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.

In what sense does Go do this right?

It does right this not, this right. It's accessible to every go program: https://golang.org/pkg/crypto/tls/

I've never heard someone use right this, is that similar to exactly this or just this?

Yeah, 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).

Hmm 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.

No problem :)

Http and https is accessible to every Rust program as well. It just has to be opt-in in Cargo.toml

Go 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.

Seeing 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.

Rust has HTTP and HTTPS support. You just have to enable it in your Cargo.toml.

The ecosystem is part of rust.

To you, perhaps, but I wholeheartedly disagree.

Rust will have support only when it is included in the standard library.

If 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.

You may have been correct 20 years ago, but I don't believe this argument holds water nowadays. HTTP APIs are everywhere from being required to control small embedded systems to interacting with large complex daemons. These usecases are exactly the space where Rust/stdlib is meant to be used.

Rust has included TCP and UDP in the standard library* because it was rightly recognized that these protocols, like stdio and filesystem io, have become fundamental to how most modern software interacts with its environment (system, IPC). HTTP today has also become fundamental in a similar manner. I argue that it is time that we treated it as such.

* as apposed to leaving them as an external dependency, like mio.

I 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

Implementing crypto is much much harder than simply providing abstractions over the OS' TCP/UDP APIs.

Far better to let the experts do it.

That's not really an argument against having it in stdlib, though?

It'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.

Tls is part of Golang’s stdlib

Many 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.

I'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) { ... }

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.

Reply on news.ycombinator.com