On 2/15/2018 9:13 AM, Patrick Brunschwig wrote:

I would be in favor of this.

Generally there seems to be interest in better PGP support in
Thunderbird. Discussions of incorporating Enigmail generally focus on
whether it is an adequate solution, not on the overall concept of better
PGP support. Making installation of a support library less problematic
would help (as long as the license is acceptable).

There is also the precedent that we support a binary ical library to
support the Lightning extension. I've also had core changes done to
support my own complex extensions, that are generally acceptable as long
as the libraries are not limited to use by a particular solution. Some
of these (like support for JS-written search terms and filter actions)
have gone on to be used by other extensions.

:rkent

On 2/15/18 6:13 PM, Patrick Brunschwig wrote:

One thing I read recently is there would xpcom bindings for rust, so
that Sequoia could be easily exposed. I'm not sure what the state of
that is though. I think encryption is an important part of Thunderbird
and I would want to see improvements in this area, so I am also in favor.

Philipp

I agree encryption is something we want to give support to.

What kind of speed difference are you expecting? If it's not significant
and there aren't other quality aspects to consider, then a JavaScript
implementation surely is an easier way to go - also allowing the gpg
implementation to ship with Enigmail where it's used.

So I'm interested in some real world numbers :)

 -Magnus

On 15-02-2018 19:13, Patrick Brunschwig wrote:

On 2/15/2018 12:13 PM, Patrick Brunschwig wrote:

My answer is a qualified yes. There are some criteria that need to be
understood, though:

1. What is the license?
2. What libraries does it pull in? How many of these are we already
   vendoring in mozilla-central?
3. Who is primarily responsible for maintaining the code, and who is
   responsible for delivering new versions, both for new functionality and
   for security updates?
4. Particular concerns: how are the networking and the cryptography for
   the library being provided? I definitely want to avoid a scenario where
   we're linking into openssl/schannel, and I'd be wary of cryptography
   being provided by hand-rolled code.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

On 16.02.18 21:05, Magnus Melin wrote:

I can't compare Sequoia with OpenPGP.js yet (that would need a bit more
time), but I did a comparison using GnuPG 2.2.4 vs. OpenPGP.js with
today's Thunderbird 60.0a1.

I did a comparison by generating 5 RSA keys (3072 bit) each:
GnuPG:      1 - 3 seconds per key
OpenPGP.js: 25-30 seconds per key

It seems pretty clear that there's a significant difference between
OpenPGP.js and GnuPG. I'd expect Sequoia to be in the same order of
magnitude as GnuPG.

-Patrick

On 17.02.18 02:37, Joshua Cranmer 🐧 wrote:

Below the answers from the developers:

The license hasn't been decided yet. It looks like it will be LGPL,
decision to be taken by end of February.

Currently, for the core OpenPGP functionality, we depend on:

• libnettle (for the crypto)
• miniz for deflate & zlib support
  (https://github.com/alexcrichton/flate2-rs)
• libbz2 for bz2 support (https://github.com/alexcrichton/bzip2-rs)

For the store, we use sqlite.

We also use a bunch of Rust packages, as is usual in the Rust
ecosystem.

There are currently three people employed by pep to work on Sequoia:
Justus Winter, Kai Michaelis and Neal Walfield.  Since we are not
feature complete yet, we haven't thought that much about security updates.

After evaluating several alternatives, we settled on libnettle, which
appears to be well respected by the crypto community.  We explicitly
didn't choose libgcrypt due to side-channel concerns and a lack of
adoption outside of gpg.  We also opted to not use the native Rust
crypt library, because they warn developers to not use it yet.

-Patrick

On 2/19/2018 6:46 AM, Patrick Brunschwig wrote:

LGPL is the one license where I can't give a definitive answer. My
recollection is that the LGPL linking requirements may cause issues, but
since we're talking about a Rust library, this is probably a much
simpler path forward than for a JS LGPL library. I've CC'd Gerv in the
hopes that he can give a better answer than I.

Is there no need for http[s] or TLS in general? (I don't know what
protocols are used to talk to keyservers). If that need is absent, then
there is a lot less concern about the exact choice of library (beyond
obvious concerns like crypto attackability, which I'm not qualified to
evaluate and hence I'm ignoring).

It would be nice if you could use NSS instead of libnettle for the
various crypto implementations, but I'm not going to require it or even
say any more on it. It's also not clear to me if you considered ring for
crypto primitives, although I do completely understand rejection (the
crate is geared towards newer crypto and lacks implementations of legacy
crypto like MD5. What it does implement should be production-quality,
though).

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

On 22.02.18 02:51, Joshua Cranmer 🐧 wrote:

Keyservers are accessible via the HKP protocol, which is a protocol on
top of http(s). But the protocol is very simple, Enigmail already has
its own implementation in JavaScript using XMLHttpRequest. That is, we
could probably disable networking access from the library.

-Patrick