> 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. They don't support those things now, but will they support them on Servo's timeframe? > I believe this is what was meant by suggesting we follow these projects' progress and adapt our decisions along the way. If this means "start on NSS bindings now and then (consider) switching over once the native Rust solutions are Web compatible", then I think we should carefully consider the downsides to this. We risk doing a lot of work that will just be thrown away later, as well as the technical debt that comes with ripping out old dependencies and replacing them with new ones. "The native Rust solutions don't support X and Y" are not necessarily slam-dunk arguments to work on alternatives; it may be less work to just implement X and Y in those projects. > No solution here involves zero work for us, but using NSS seems to involve the least work aside from doing nothing. That may be true as far as rusttls/libwebpki are concerned (though I'm not convinced), but it doesn't seem to be true for rust-native-tls. > 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. Yeah, I should have said "Firefox" or "the NSS project" instead of Gecko. The same arguments apply. Patrick On Fri, Aug 26, 2016 at 10:29 AM, Jack Moffitt <j...@metajack.im> wrote: > > 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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
