Re: gnutls status

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 26 Nov 2010 01:28:46 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Julien Danjou <julien@danjou.info> writes:
>> gnutls support has been added to Emacs 24. What's the status of it?

LMI> It seems to work.

It's missing some features.  See
http://thread.gmane.org/gmane.emacs.devel/131441/focus=131551 and the
rest of that thread for the details.  The biggest one is callbacks.

We need callbacks to implement host name verification and certificate
chain checking, which are both IMO essential to making the Emacs GnuTLS
support "official."  In GnuTLS 2.8.x you can't set a callback function,
so the C code would need (from doc/examples/ex-rfc2818.c):

  if (gnutls_x509_crt_get_expiration_time (cert) < time (0))
    {
      printf ("The certificate has expired\n");
      return;
    }

  if (gnutls_x509_crt_get_activation_time (cert) > time (0))
    {
      printf ("The certificate is not yet activated\n");
      return;
    }

  if (!gnutls_x509_crt_check_hostname (cert, hostname))
    {
      printf ("The certificate's owner does not match hostname '%s'\n",
              hostname);
      return;
    }

which is very inflexible compared to a callback function.  We'd need to
add custom API options for each of the three checks above plus another
for the certificate chain verification; in addition it would be harder
to interact with the user and store trusted certificates from C.

2.10.x and above let us set a callback function, which would make all of
the above easier and more convenient from ELisp-land.  The problem is
that 2.10.x hasn't been widely adopted in Debian and thus won't work by
default.

So we'd need to either 1) require 2.10.x, or 2) complicate the C code
and API using just 2.8.x features and maybe figure out how to set up our
own callback mechanism, or 3) use the 2.10.x features only when it's
available, using autoconf detection, which is twice as complicated as
(2).

(2) and (3) will require a lot of new code that is completely
unnecessary under 2.10.x.

This is essentially why I haven't worked on the GnuTLS support in a bit:
I don't know the best way forward.  If anyone can suggest a good way to
do it, I'm all ears.  I also don't know about 2.10.x's status in the
major distros and whether Emacs can require that version or higher
specifically.

>> Could we use it in Gnus? Or is this still an Emacs side problem to
>> resolve?

LMI> nnimap has support for using it, but it's probably the wrong place to
LMI> put the support.  It should be put into tls.el, probably, so that all
LMI> the users don't have to know about the stuff...

I think every package should explicitly choose to support gnutls.el, it
shouldn't be an Emacs-wide choice.  There's too many configuration
options that depend on the purpose.  For instance IMAP and HTTPS have
really different security needs.  Also, GnuTLS is much more configurable
than the older command-line interfaces so normalizing the API is not so
easy.  This is why I removed the old tls.el compatibility code from
gnutls.el and it only has gnutls-* functions now (`open-gnutls-stream'
and `gnutls-negotiate' being the main entry points from the ELisp side,
while `gnutls-boot' is the main entry point from the C side).

IMO tls.el and friends should be made deprecated as soon as gnutls.el is
capable to verify a certificate chain, the expiration date, and the
hostname.  They are insecure and the cause of many bug reports over the
years, especially on the W32 platform.

As with the C issues above, if you have opinions or suggestions on how
to do all this better, including Gnus but also for Emacs in general,
tell me.  I'm CC-ing to emacs-devel as well.

Ted