From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: serving ELPA over HTTP/S Date: Tue, 05 May 2015 13:38:40 -0400 Message-ID: References: <87oam08ofr.fsf@lifelogs.com> <87k2wo8kd7.fsf@lifelogs.com> <87d22g8h7d.fsf@lifelogs.com> <871tiw86ez.fsf@lifelogs.com> <87k2wn9ket.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430847569 6563 80.91.229.3 (5 May 2015 17:39:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 May 2015 17:39:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 05 19:39:18 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YpgoM-0005fy-HN for ged-emacs-devel@m.gmane.org; Tue, 05 May 2015 19:39:14 +0200 Original-Received: from localhost ([::1]:40984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpgoL-0002cj-Ld for ged-emacs-devel@m.gmane.org; Tue, 05 May 2015 13:39:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpgoI-0002cS-NI for emacs-devel@gnu.org; Tue, 05 May 2015 13:39:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpgoE-0000da-EX for emacs-devel@gnu.org; Tue, 05 May 2015 13:39:10 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:59071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpgoE-0000dN-AA for emacs-devel@gnu.org; Tue, 05 May 2015 13:39:06 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id A136F85C9A; Tue, 5 May 2015 13:39:05 -0400 (EDT) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 846751E5B8D; Tue, 5 May 2015 13:38:40 -0400 (EDT) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 61799B41A0; Tue, 5 May 2015 13:38:40 -0400 (EDT) In-Reply-To: <87k2wn9ket.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 05 May 2015 10:19:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186252 Archived-At: > http://blog.codinghorror.com/should-all-web-traffic-be-encrypted/ or in > the proposed HTTP 2.0 standard. You may disagree, but I think the burden > of proof today should be on those who want to *disable* encryption. I largely agree, but at the same time, we've been running without even any kind of signature verification until very recently, and even Debian works without https, so clearly it's not that big of deal. > If the user doesn't have GnuPG installed (and we've agreed to treat that > as an acceptable situation, right?), I could agree to emitting a warning if neither of gnutls nor gnupg are available. And I don't see a good reason to let the user turn the warning off (after all, she can turn it off by installing gnupg). >>> 1) so ELPA archives can have multiple URLs. Assuming there's just one is >>> not ideal in the long term. SM> That's a separate issue, unrelated to http/https. > And yet it would also be addressed by my proposal, so I think it's worth > considering. I'm not opposed, but I think it's much more complex than just using https by default when it's available. Having several URL with a failover from one to the other, opens up the issue of timeouts and other forms of failures, which can be pretty ugly, so will require more care in the implementation to make it work well enough (after defining what "well enough" should be in this context). Stefan