Re: [dev-servo] Proposal: TLS library for Servo

2016-09-26 Thread Olaf Buddenhagen
Hi, On Thu, Sep 22, 2016 at 06:53:47PM -1000, Brian Smith wrote: > Olaf Buddenhagen wrote: > > Sorry for being late to this discussion, but I feel the need to remind > > everyone of the infamous OpenSSL licensing problem, i.e. the fact that > > the SSLeay license it is (partially) covered by is

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-22 Thread Brian Smith
Olaf Buddenhagen wrote: > Sorry for being late to this discussion, but I feel the need to remind > everyone of the infamous OpenSSL licensing problem, i.e. the fact that > the SSLeay license it is (partially) covered by is considered > GPL-incompatible by many -- including (among others) the Debi

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-21 Thread Olaf Buddenhagen
Hi, Sorry for being late to this discussion, but I feel the need to remind everyone of the infamous OpenSSL licensing problem, i.e. the fact that the SSLeay license it is (partially) covered by is considered GPL-incompatible by many -- including (among others) the Debian project. This affects not

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-07 Thread Jack Moffitt
> Also, brand new-ness is not just a bad thing; > it also means that rustls can take advantage of modern knowledge on > what areas of TLS are more or less important and more or less > vulnerable. Several people heavily involved in the TLS standards process are at Mozilla and work on NSS. NSS and B

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-07 Thread Dirkjan Ochtman
On Wed, Sep 7, 2016 at 12:41 AM, Diane Hosfelt wrote: > I 100% understand the desire to use a pure Rust TLS library for Servo, but > I think we need to not ignore the fact that there isn't one right now. Ring > implements the crypto primitives, not the protocols. Rustls is promising, > but it's br

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-06 Thread Diane Hosfelt
Thanks for the info about mozilla::pkix. I think that webpki looks like it might be the right answer for a certificate library. I 100% understand the desire to use a pure Rust TLS library for Servo, but I think we need to not ignore the fact that there isn't one right now. Ring implements the cryp

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-06 Thread Brian Smith
On Tue, Sep 6, 2016 at 11:38 AM, Jack Moffitt wrote: > > Outside of the NSS team, who has more confidence in NSS than *ring* + > > webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning? > > I think the assumption here is that many people outside the current > Rust community would hav

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-06 Thread Jack Moffitt
> Outside of the NSS team, who has more confidence in NSS than *ring* + > webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning? I think the assumption here is that many people outside the current Rust community would have more confidence in NSS, BoringSSL, or OpenSSL than Ring + rust

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-06 Thread Brian Smith
Jack Moffitt wrote: > 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. Th

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-06 Thread Brian Smith
On Thu, Sep 1, 2016 at 10:43 AM, Jack Moffitt wrote: > 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

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-06 Thread Jack Moffitt
> NSS doesn’t currently support building as static libraries. Do you think it > would be better to try to use the system NSS or ship the libraries? Depending on the system one exclusively is one reason why our OpenSSL bindings suck. So we have to have it built by Cargo as a fallback. jack. _

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-06 Thread Diane Hosfelt
NSS doesn’t currently support building as static libraries. Do you think it would be better to try to use the system NSS or ship the libraries? Diane > On Sep 5, 2016, at 10:16, Ms2ger wrote: > > On 26/08/16 02:13, Diane Hosfelt wrote: >> Proposed Development >> >> I propose to create Rust b

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-05 Thread Ms2ger
On 26/08/16 02:13, Diane Hosfelt wrote: > Proposed Development > > I propose to create Rust bindings for NSS, which is the crypto library used > to secure Firefox. Not only does it fulfill all of Servo’s requirements, > but it already has support for future work like TLS 1.3. I also propose > that

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-05 Thread Ms2ger
On 02/09/16 16:26, Jack Moffitt wrote: > If NSS bindings [...] provide a better build experience, FWIW, I haven't heard a good word about the NSS build experience in the years that I've been around, and plenty of bad ones. Ted's work to move NSS to gyp [1] might change that, though. (OTOH, Servo

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-04 Thread Brian Anderson
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.

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-03 Thread Patrick Walton
> 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 w

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-02 Thread Jack Moffitt
> 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

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-02 Thread Dirkjan Ochtman
On Thu, Sep 1, 2016 at 10:43 PM, Jack Moffitt wrote: > 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 b

Re: [dev-servo] Proposal: TLS library for Servo

2016-09-01 Thread Jack Moffitt
> 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

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-31 Thread Patrick Walton
> In my opinion, web compatibility should be a goal of Servo. I agree. However, it's worth noting that layout and DOM bugs and missing functionality currently prevent far more than 7% of Web sites from working. In these areas, it will take significant time to get to 90%+ Web compatibility. (Grante

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-31 Thread Robert O'Callahan
On Thu, Sep 1, 2016 at 12:57 PM, Diane Hosfelt wrote: > Right now, what I’m working on is updating some TLS statistics using > https://github.com/mozilla/cipherscan cipherscan> (it’s taking a bit longer than I’d originally anticipated). > Based on my current results

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-31 Thread Diane Hosfelt
Hi all-- Thanks for everyone’s comments about this—I think the discussion has been really illuminating. Right now, what I’m working on is updating some TLS statistics using https://github.com/mozilla/cipherscan (it’s taking a bit longer than I’d original

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-29 Thread adelarsq
Hi, just want to point that using independent Rust libraries may be good to avoid problems like this: https://github.com/sfackler/rust-openssl/issues/255 Adelar ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/de

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-29 Thread Gervase Markham
On 26/08/16 15:11, Brian Anderson wrote: > There are many benefits to this approach. Advancing Rust crypto is > perennially a high-priority strategic nice-to-have in Rust, but so far we > have not been able to find the right motivation to put weight behind it. > Any time there is a glimmer of oppor

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Brian Smith
On Fri, Aug 26, 2016 at 1:59 PM, Brian Smith wrote: > I am proud of the work that David Keeler, Camilo Viecco, and I > did on mozilla::pkix. Sorry to reply to my own post. I just wanted to point out two things: Matt Wobensmith, the QA person that we worked with on mozilla::pkix, was a major facto

[dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Brian Smith
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 c

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Jack Moffitt
> So, got any good research papers on networking? My undestanding is that I/O is the bottleneck for networking, not the CPU. So research here tends to focus on elimination of network requests, optimizations to solve overhead (pipelining, keepalive), more efficient protocols, or better data compres

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Michael Howell
So, got any good research papers on networking? On Fri, Aug 26, 2016, 12:06 PM Josh Matthews wrote: > On 2016-08-26 2:03 PM, Brian Anderson wrote: > > While I still have the mic I'll make an argument in favor of NSS in > Servo: > > if there is a goal to move Servo's network stack into Firefox in

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Josh Matthews
On 2016-08-26 2:03 PM, Brian Anderson wrote: While I still have the mic I'll make an argument in favor of NSS in Servo: if there is a goal to move Servo's network stack into Firefox in the near/medium term, then that is strong reason to give Firefox's requirements weight over Rust's. I'm not aw

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Patrick Walton
> 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?

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Brian Anderson
Hi Jack <3 On Fri, Aug 26, 2016 at 10:29 AM, Jack Moffitt 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 li

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Jack Moffitt
> 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 we

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Patrick Walton
First of all, thanks for putting this together! 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. *ring* *is* BoringSSL -- at least the crypto primitives from it -- wrapped into a nice Rust

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Brian Anderson
Fun topic! Rust crypto is super important. My perspective on this is from someone who wants the greatest benefits for Rust. Whatever the decision I hope you enjoy hacking on Servo. On Thu, Aug 25, 2016 at 5:13 PM, Diane Hosfelt wrote: > Servo has been using the cryptographic library, OpenSSL (vi

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Gavin Sharp
> NSS also has a fairly bad security record, with 6 CVEs in 2015 and 4 > in 2016 until now (with the most recent one fairly high-risk). "number of CVEs over time" is a poor way to evaluate software security, because the number of issues found is proportional not only to code quality or development

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread eternaleye
Replies inline. On Thursday, August 25, 2016 at 5:14:22 PM UTC-7, Diane Hosfelt wrote: > Options > >1. > >Continue to use existing OpenSSL bindings >2. > >Contribute to a new or existing library in Rust >3. > >Create bindings to another existing library 4. Use exist

Re: [dev-servo] Proposal: TLS library for Servo

2016-08-26 Thread Dirkjan Ochtman
Hi Diane, Thank you for bringing this discussion into the open. On Fri, Aug 26, 2016 at 2:13 AM, Diane Hosfelt wrote: > This is our current solution. While trying to distribute nightlies, the > team discovered that the Rust bindings for OpenSSL need some work1. > Additionally, many projects are

[dev-servo] Proposal: TLS library for Servo

2016-08-25 Thread Diane Hosfelt
Servo has been using the cryptographic library, OpenSSL (via the Hyper library) for securing communications. As the project transitions to shipping nightly builds and hopefully products, we need to make a more explicit decision about our library usage. As a web browser, there’s a high standard to m