Patrick Walton wrote: > *ring* *is* BoringSSL -- at least the crypto primitives from it -- > wrapped into a nice Rust library.
Originally, *ring* could accurately be described as a subset of BoringSSL. Then it became a subset of BoringSSL wrapped in Rust. Since then we've replaced a lot of the C code in BoringSSL with Rust code, and we've made many improvements to the C code beyond what I've been able to contribute to BoringSSL. Consequently, saying that *ring* is BoringSSL is actually short-changing *ring* because we've improved upon BoringSSL in several areas. In particular, a lot of important crypto stuff is already done in Rust in *ring* and we're using improved techniques that haven't been adopted in BoringSSL, OpenSSL, or NSS yet. (Note: I'm sure that you don't mean to short-change *ring*; my point is that we shouldn't be questioning how much worse *ring* is than alternatives, but rather questioning how much better it is, which is probably surprising to many people.) But also saying *ring* is BoringSSL doesn't given enough credit to the BoringSSL team for the stuff that they've improved that wasn't needed in *ring*. For example, they implemented SPAKE2 and NewHope and TLS 1.3, none of which are included in *ring*. And Google has done an absolutely incredible job with testing BoringSSL that is way too easy to under-appreciate. The *ring* project is lucky to build upon all of that. I think both teams are doing a great job in different ways. Regarding mozilla::pkix and webpki: I am proud of the work that David Keeler, Camilo Viecco, and I did on mozilla::pkix. I actually tried to create Rust bindings for mozilla::pkix, but I found it was easier to create the pure-Rust webpki instead. Based on my experience, I predict it would be a significant amount of work to create really usable bindings for mozilla::pkix, and I doubt you'd like the resulting code much if you did it. I didn't include OCSP in webpki because I had written the OCSP code at Mozilla and so Mozilla Corp. has the copyright on it, so I couldn't port it to Rust with the better license that webpki has. In contrast, I own the copyright on most other parts of mozilla::pkix that were useful for creating webpki, because I wrote them after leaving Mozilla; this greatly sped up the creation of webpki because I didn't have to take the "clean room" approach I had to take for some other parts. If Mozilla were to contribute the existing C++ OCSP code from mozilla::pkix to the webpki project under the webpki license, this would greatly speed up the addition of OCSP support to webpki. I have some plans for how to support the bad crypto in TLS 1.0 and TLS 1.1 in a way that doesn't put other users of *ring* at risk of misusing them. That's something that's better discussed privately for now, as there's non-technical factors to consider. Note that Rustls is Joseph Birr-Pixton's project, and so even if I were to somehow support the bad crypto that TLS 1.0 and TLS 1.1 require, Rustls may choose not to do so. If a major goal of the Servo project is still research into how Rust and Rust-like languages can improve the current sad and dangerous state of software, then I think it's clear that Servo should prefer to use libraries that are are in line with that goal. I think *ring* and webpki and Rustls are good examples of such libraries. *ring* is interesting because it shows how to evolve a pure C + asm library into what will become something close to a Pure Rust + asm library incrementally. webpki is interesting because it shows how to do a from-scratch rewrite of an existing library. Rustls is interesting because it shows how to create a from-scratch security-oriented library. And, of course, they all provide incredibly useful functionality and are all written in modern, security-first mindset, beyond being good examples to learn from. Further, as we move more of the *ring* functionality into Rust we push the limits of Rust, which will help Rust improve, which benefits not just *ring*, but many other Rust-based projects. Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
