From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Emacs core TLS support Date: Wed, 29 Sep 2010 12:06:32 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87k4m4zdgn.fsf@lifelogs.com> References: <878wc1vfh3.fsf@lifelogs.com> <87r5i2d00q.fsf@lifelogs.com> <87zkwqijye.fsf@stupidchicken.com> <878w4actmg.fsf@lifelogs.com> <877hju123h.fsf@stupidchicken.com> <8762yklrdk.fsf@lifelogs.com> <87wrqzhrjv.fsf@lifelogs.com> <87fwxmihyz.fsf@lifelogs.com> <8762ycfhqo.fsf@lifelogs.com> <87d3sf9soo.fsf@lifelogs.com> <87r5gh2fzj.fsf@lifelogs.com> <87zkv38cy5.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1285780759 8772 80.91.229.12 (29 Sep 2010 17:19:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Sep 2010 17:19:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 29 19:19:16 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P10JH-0004D9-5y for ged-emacs-devel@m.gmane.org; Wed, 29 Sep 2010 19:19:15 +0200 Original-Received: from localhost ([127.0.0.1]:44049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P10JG-0006qk-8b for ged-emacs-devel@m.gmane.org; Wed, 29 Sep 2010 13:19:14 -0400 Original-Received: from [140.186.70.92] (port=47013 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P108E-0000qj-Qk for emacs-devel@gnu.org; Wed, 29 Sep 2010 13:08:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P107F-0005RH-Ql for emacs-devel@gnu.org; Wed, 29 Sep 2010 13:06:53 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:55140) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P107F-0005R1-Cc for emacs-devel@gnu.org; Wed, 29 Sep 2010 13:06:49 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P107D-0007tG-B0 for emacs-devel@gnu.org; Wed, 29 Sep 2010 19:06:47 +0200 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Sep 2010 19:06:47 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Sep 2010 19:06:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 80 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:soV2MlObCQLzEVsnbwgQsrdqZyk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:131080 Archived-At: On Wed, 29 Sep 2010 14:53:48 +0200 Lars Magne Ingebrigtsen 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 wrote: LMI> Lars Magne Ingebrigtsen 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