There are two things I can think of that are barriers to adoption as a general rust solution: the mpl, and build complexity.
All critical components of the rust stack have a permissive license, but nss is mpl. I don't see myself supporting nss as the default rust TLS stack for this reason alone. I'm not sure of the build deps for nss, but the ultimate solution for rust will be limited to rust, c, and asm, and will be buildable with nothing but cargo, GCC, and gcc-rs. I do think it will take time yet for rust crypto to mature enough for general use, but in the meantime we will necessarily need to maintain the openssl bindings anyway (or move to boringssl), as the interim rust solution. On Sep 3, 2016 11:19 AM, "Patrick Walton" <pwal...@mozilla.com> wrote: > > 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. > > If this is true, then I suspect the reason is that the Rust community is > more interested in putting effort into the native Rust crypto stack: > *ring*, libwebpki, and rustls. > > The availability of high-quality NSS bindings is not likely to change the > general desire of the Rust community to focus on the native Rust stack. > That's because practical crypto is an area that plays to Rust's strengths > as a language. > > I concur with Dirkjan that it's likely that we will be one of the few Rust > users of NSS if we go down this route, and we may be effectively isolating > ourselves from the rest of the community. > > Patrick > > On Fri, Sep 2, 2016 at 7:26 AM, Jack Moffitt <j...@metajack.im> wrote: > > > > 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 > > > _______________________________________________ > 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
