From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/74418 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: gnutls status Date: Fri, 26 Nov 2010 15:10:39 +0100 Organization: Programmerer Ingebrigtsen Message-ID: References: <87ipzkmgfn.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1290780690 18676 80.91.229.12 (26 Nov 2010 14:11:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 26 Nov 2010 14:11:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: ding@gnus.org Original-X-From: ding-owner+M22782@lists.math.uh.edu Fri Nov 26 15:11:23 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PLz1H-00016Y-JS for ding-account@gmane.org; Fri, 26 Nov 2010 15:11:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1PLz0t-0007Kc-NG; Fri, 26 Nov 2010 08:10:59 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1PLz0r-0007KP-Kq for ding@lists.math.uh.edu; Fri, 26 Nov 2010 08:10:57 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1PLz0m-0005lM-O5 for ding@lists.math.uh.edu; Fri, 26 Nov 2010 08:10:57 -0600 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1PLz0m-0001GE-00 for ; Fri, 26 Nov 2010 15:10:52 +0100 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PLz0l-0000mf-Lq for ding@gnus.org; Fri, 26 Nov 2010 15:10:51 +0100 Original-Received: from cm-84.215.34.171.getinternet.no ([84.215.34.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Nov 2010 15:10:51 +0100 Original-Received: from larsi by cm-84.215.34.171.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Nov 2010 15:10:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 47 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.34.171.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUAAAAAAAMCAQECAQUB AAMoJCUCAQP1HVz3AAACX0lEQVQ4jU2T0XLjIAxFSerJc7LLB7iZzD63K+JnExR+AOPnbKH8/yfs lXDTMpPY5qAr6Vo2pq/9n9Fcck6EX0reDGbsYBz3+7DmlGUtnuMWYOZxPHNdW0k0rc76J+D5fL4v iwbk5O034PPlLnsp01qZ+Qm8ZwVrnpbqOejuDuA2sEglUUvhSgqG+RIrzwe30LqgsFQySaGXYX6N zLNBoW39XFZ0Q2Y/MFvGPvMLzrZ0XdcsgGSLb2zG/R1nAZBEgUVBMwwYbneYASAVAxQr6maQuJxX AT3HQ/eNChoXWyFaAxGZo3p7NJJnrNwaAAvoFqpUSHWukSjJn+m+a4qQ263GRmvkskUM0gisqw0g wsS4ARMbIuLI8QNgwpEvMLQWaxzP58ehSaiC0Z84UENMexwAvAQD/MLVhalKqdWMKqrJYYmENg51 qtBTIOVqz7hroU0RVVWtnAyOe7mhiWKDIa0SRzwaxexgQiwVRgEQFQEOMq7IU50aqqtiIUAgx0Gk ysRTkAhJqIB8cHKq6KUVx88IIg0vkklA6ACiXZYmSV6oA9nY9klzFHIbcF7BNSt8AnbvPUCGCh8O 5Jwmt247jnEqAG2TNVYvn5mSzhmA+wmuif5q99QcfXW+Ld1gKvjYwncOunbIKNnFDrQd6rVycM1y oR/ga3E7bSa+KgjO6yMdHsbCPkdmJ2+K550LMhvl8MDwefQOgE/UmRd4+g+vKX6wtVaAGU4c3w0y hhmiMiRW3jQG7mTjm+Hf5M31MbxhvI+2A1t4HniIR0tzmA8VWjIlO8wnamaHeUdnuGPt4D8yCP7p Q9R2HwAAAABJRU5ErkJggg== Mail-Copies-To: never X-Now-Playing: Radian's _Radian_: "Git Cut Noise" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:sjQVoVZrFZ8CJI6GCTZP/yhlL54= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:74418 gmane.emacs.devel:133165 Archived-At: Ted Zlatanov writes: > 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). Is 2.10.x at least backwards-compatible, so that if we do implement the complicated 2.8.x features, it'll continue to work in the future, too? > 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. True. On the other hand, look at `nnimap-open-connection' and weep. It started off as a simple function and grew into a monster. That's why I haven't adapted nntp/pop3/etc to use gnutls yet -- I don't want to have to repeat the same code all over the place. And the STARTTLS situation, in particular, is a nightmare, since the sane gnutls way of doing it and the really awkward starttls.el way of doing it require different code paths. And we're going to have to support gnutls/tls.el/starttls.el in all the connections for the unforeseeable future. I kinda want to write a new connection framework that'll just separate out all this cruft into a separate package, but I can't really see a sensible unified interface. Especially with the STARTTLS stuff. I mean, ideally, in the future whenever you do a pop3/imap/nntp/smtp/etc connection, Emacs should opportunistically switch on STARTTLS if the server supports it. Encryption is good. Switching on STARTTLS is virtually free if you have gnutls. It's really expensive if you don't. I mean, time-wise for the user. But I don't really see an easy way to do that. You'd need protocol-specific callbacks and stuff. And I hate frameworks. And it'll be brittle, anyway, since starttls.el is kinda brittle. But I do think we need some kinda of compat library to avoid going totally insane. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen