Re: Emacs core TLS support

[Ted Zlatanov]

On Wed, 29 Sep 2010 14:53:48 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> But I've now committed what I've done, since it's actually usable now,
LMI> and it's really fast!  It takes like a fraction of the time that tls.el
LMI> uses, what with the gnutls-cli forking and stuff.

On Wed, 29 Sep 2010 15:25:41 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Lars Magne Ingebrigtsen <address@hidden> writes:

>> That is, emacs_gnutls_read should do the handshake, basically.

LMI> What the hey.  I implemented it, and it seems to work for me.

Thanks so much, you rock.  So now it's time to actually work on the
API.  That's the easy part after you did all the hard work making it
actually run :)

The ELisp entry point is:

(defun starttls-negotiate (proc &optional priority-string
                                credentials credentials-file)

That's not very good since we also need a trust file, a callback for
some credentials, and possibly more parameters (there's three kinds of
credentials and only two are implemented currently, but they all need
different things).  So I think the parameters should be an alist or a
plist, probably a plist since the parameters will be well-defined.  The
user should probably be able to override them globally in the typical
alist keyed by server name.

I would also rename the function above to `gnutls-negotiate' and
generally keep everything in gnutls.el with the gnutls- prefix.  So:

(defun gnutls-negotiate (proc &rest params)

The C entry point:

DEFUN ("gnutls-boot", Fgnutls_boot, Sgnutls_boot, 3, 7, 0,
       doc: /* Initializes client-mode GnuTLS for process PROC.
...
PRIORITY_STRING is a string describing the priority.
TYPE is either `gnutls-anon' or `gnutls-x509pki'.
TRUSTFILE is a PEM encoded trust file for `gnutls-x509pki'.
KEYFILE is ... for `gnutls-x509pki' (TODO).
CALLBACK is ... for `gnutls-x509pki' (TODO).
LOGLEVEL is the debug level requested from GnuTLS, try 4.
...
    (Lisp_Object proc, Lisp_Object priority_string, Lisp_Object type,
     Lisp_Object trustfile, Lisp_Object keyfile, Lisp_Object callback,
     Lisp_Object loglevel)

Should be similarly reworked and made more robust to catch errors.  So:

DEFUN ("gnutls-boot", Fgnutls_boot, Sgnutls_boot, 3, 7, 0,
       doc: /* Initializes client-mode GnuTLS for process PROC.
...
PRIORITY_STRING is a string describing the priority.
LOGLEVEL is the debug level requested from GnuTLS, try 4.
PARAMS is a plist of parameters, see below.
...
    (Lisp_Object proc, Lisp_Object loglevel, Lisp_Object params)

Generally I'd like to make the API less of an override to ssl.el and
starttls.el and more of a standalone facility.  So `open-ssl-stream' and
`starttls-open-stream' would not be provided by gnutls.el.  It would
provide `open-gnutls-stream' with a required parameters alist/plist,
which then calls `gnutls-negotiate'.

Yes, that means that older code won't work directly with gnutls.el, but
the GnuTLS is just much richer than ssl.el or starttls.el.  I don't want
packages authors to say "oh I can open a stream and It Just Works" but
instead they should at least look at the docstring and understand what
they are providing to their users.

Finally, I did not explore making Emacs a SSL/TLS server.  I think
that's not really useful without threads, but if anyone has an amazing
reason to do it, please speak up.

Ted