> I'm in agreement with Brian that *ring* and rustls seem like the way to go > first. Second, I would suggest rust-native-tls as a backup if it doesn't > work out.
rusttls doesn't seem to support TLS 1.1, which seems like a non-starter. We'll probably want to dig up some data on how much of the web relies on that. libwebpkix does not yet support revocation checking. I believe this is what was meant by suggesting we follow these projects' progress and adapt our decisions along the way. > Fundamentally, I think that we shouldn't underestimate the amount of effort > it'll take to write and maintain idiomatic Rust bindings to a TLS library > ourselves. Rust isn't C or C++: the fact that Rust has an excellent FFI > doesn't negate the fact that using a C library in practice isn't as simple > as just importing it. There's a lot of value in leveraging existing > community bindings to libraries. The NSS team has offered their help to create the bindings and maintain and host them in tree. No solution here involves zero work for us, but using NSS seems to involve the least work aside from doing nothing. > Finally, I don't see any particular reason why Servo using NSS would help > Gecko. I don't think this was part of the requirements. As you stated there are some mild benefits for NSS exposure with that option, but none of the options presented benefit Gecko very much. jack. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
