[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A couple of questions and concerns about Emacs network security

From: Jimmy Yuen Ho Wong
Subject: Re: A couple of questions and concerns about Emacs network security
Date: Sat, 23 Jun 2018 11:34:43 +0100

On Sat, Jun 23, 2018 at 7:45 AM, Eli Zaretskii <address@hidden> wrote:
> From: Paul Eggert <address@hidden>
> Date: Fri, 22 Jun 2018 15:43:35 -0700
> Cc: Lars Magne Ingebrigtsen <address@hidden>
> > 2. Now that `starttls.el` and `tls.el` are obsolete, and GnuTLS doesn't
> >     seem to be doing a very good job, can we link to something better
> >     maintained, such as OpenSSL/LibreSSL/BoringSSL/NSS?
> I would think the answer to that could be "yes" too. Despite its name,
> GnuTLS is no longer GNU code, and we're under no obligation to promote
> it. However, this would take some work. We'd surely want the option to
> link to either GnuTLS or OpenSSL/etc.

GnuTLS may not be a GNU project in the formal sense, but nothing has
changed in its development methods or in its spirit since it was.
OpenSSL is even less of a GNU project, and AFAIR includes components
that are not even Free Software.  Moreover, having 2 different
libraries for the same task in Emacs will be a maintenance burden we
are better without, especially given the lack of active experts on
board.  I'd like to remind us all that we've just switched to GnuTLS
as the primary means in Emacs 26.1.

So my vote would be NO for switching away from GnuTLS.

While I understand this from a human resource perspective, I wonder if it's possible for the FSF to ask for some friendly help (such as the folks at EFF) on this one. I can probably ask around in London as well. In my opinion having OTTB better security is worthwhile for the switch.

As to OpenSSL, they seem to have found all the past contributors already (https://license.openssl.org/trying-to-find). It seems they are really close to switching to the Apache license. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]