emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs core TLS support


From: Ted Zlatanov
Subject: Re: Emacs core TLS support
Date: Sat, 04 Sep 2010 23:57:11 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Fri, 13 Aug 2010 20:15:30 -0400 Chong Yidong <address@hidden> wrote: 

CY> instead of

CY>    (gnutls-protocol-set-priority proc gnutls-tls1 gnutls-ssl3)

CY> it should be called as

CY>    (gnutls-protocol-set-priority proc 'gnutls-tls1 'gnutls-ssl3),
...
CY> I realize this is a rather invasive change to the patch.  I suggest
CY> separating the GnuTLS code into a separate file, gnutls.c, adding it to
CY> the Emacs repository, and work from there.

CY> Then you don't have to keep sending the patch to the mailing list.

Simon Josefsson had the suggestion that I use the string version of the
priority set and I did.  That reduces the need for this change greatly;
please take a look at gnutls.el.  There's only 

(defconst gnutls-x509pki 1)
(defconst gnutls-anon 2)
(defconst gnutls-srp 3)

for which there's actually no get_id function to look the credentials
type by name in GnuTLS.  So if that's the only thing we need to #define,
I'd rather not do anything fancy and just handle it explicitly in
`gnutls-cred-set'.

Note I've never worked with the Emacs internals at this depth so I did
not commit any of my changes to the Emacs repo and will not until you or
Stefan Monnier say it's OK.

I changed lisp.h and emacs.c to call syms_of_gnutls() and made other
changes so the patch compiles cleanly and the functions are available.
It's far from ready (it won't do anything but crash emacs) but at least
it won't break the build and doesn't affect anything else.  So it's
attached here for structural review more than any real testing.

Everything in gnutls.c that's commented out is for reference only and I
don't think will be back.  I think we should start without SRP support
and generally do just enough to get SSL and TLS to work in the simplest
cases.  When those cases work we can proceed to the fancier uses.  So
that's the current aim of the patch.

Also I think trying to make gnutls.el a drop-in replacement for
starttls.el is not a good idea.  I'd rather make it a standalone library
so we can make the API fit better.

Ted

Attachment: tls.patch
Description: Text Data


reply via email to

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