> One thing I’m also looking at is how it could be possible to make the Servo > crypto library interchangeable via traitization (I might be making up words > now). That way, people who want to use Rust crypto can do so, and people who > would prefer a wrapper of a more established library can do that. Whatever > Servo uses today doesn’t have to be the “final” decision (for whatever > definition of final you prefer, I guess).
Since we currently use OpenSSL via hyper, this means the trait would be used there. I assume we'll also need a trait for the pki parts (and those are in Servo I think). With that boundary we could replace OpenSSL with NSS and then add others as they come online. The main complication of multiple options is QA. If we don't run them through CI they are likely to bitrot quickly. > Regarding webpki—I don’t think I can disagree with Brian (since he’s > definitely the expert). I also don’t know of any additional options other > than webpki, so maybe adopting webpki is something that Servo should look > into more. mozpkix was the proposal, which Brian is also an author of. Brian, why exactly is mozpkix hard to wrap? Specific examples may help us understand Rust / C++ limitations. If that library is hard enough to wrap, then it might be less work to add whatever is needed to webpki. However, wrapping a C++ lib and implementing functionality may require quite different skillsets. One reason I would like to see the NSS bindings is that other projects in the Rust ecosystem may need more confidence in the crypto bits or functionality not yet implemented. Not every project in Rust is as pre-production as Servo. NSS bindings are also likely to be better maintained than the existing OpenSSL stuff with support from upstream. jack. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
