> You seem to have a lot of confidence in MoCo's ability to support a > project on its own, and very little confidence in the Rust ecosystem > to maintain its chosen solutions. It seems very unlikely that Rust > projects will move to NSS over OpenSSL or *ring* once bindings for NSS > are available and mature enough; you also seem to evaluate the current > state of rust-openssl and *ring*/rustls against some future where NSS > bindings exist, discounting any progress that the other projects will > make in the mean time..
The current openssl bindings are not good. Take a look at Servo's openssl related bugs for some examples. As far as I know the Rust community is not super interested in fixing this, or at least it hasn't happened yet. With most of the big players abandoning openssl in general, it is easy to see why this might be the case. The Servo community could invest in these bindings, but if we're going to divert resources, then the natural question to ask is how best to utilize them. NSS has been going strong for years powering both Chrome and Firefox for years. Chrome has recently switched to BoringSSL. Unlike Boring and other projects, it is very stable. So yes, I have some confidence that NSS will continue to be maintained and stay stable for some time, and very little of this is blind faith in my employer. If NSS bindings are more ergonomic, provide a better build experience, and are well maintained, why wouldn't the Rust community use them over the openssl bindings? You imply that the Rust community has chosen openssl as the best solution somewhere, but I think the fact it has been used so far is happenstance. Someone made openssl packages and everyone else used those because they were there. The point of this thread is to discuss the tradeoffs of different solutions. One potential benefit of NSS is that it could fix the deficiencies of the openssl solution that exists now in the Rust ecosystem. Another is that products built in Rust that don't trust young crypto code have an option that is well known. It's possible the Rust ecosystem will not be attracted to NSS, and it's also possible that everyone will have no trouble shipping rusttls. I am not discounting the progress other projects may make, and I sincerely hope to see pure Rust solutions for all parts of Servo some day. However implementing crypto code and protocols is a lot more difficult than writing bindings to an existing API, and it seems reasonable to imagine that NSS bindings will be completed in a short amount of time. > It may be comfortable from a MoCo perspective to rely on MoCo > staff/funding, but this mostly feels like "no one ever got fired for > buying IBM". Wouldn't it be great if Mozilla and the Rust community > actually aligned to advance and mature Rust crypto? How are we not aligned here? Servo has existing issues with openssl that we'd like to solve, and there are several possible solutions. The proposal suggests we choose the one that seems most likely to be available in the short term, and making sure that the work doesn't preclude adopting a different solution down the road. On top of that, Diane has been collecting data for feedback to rusttls, ring, and webpki on what features we're waiting on. This is really no different than any of the other situations we've been in where we've adopted some non-Rust dependency (freetype and font-rs are perhaps a good parallel, but without the unique trust component of crypto/protocols). jack. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
