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: serving ELPA over HTTP/S Date: Tue, 05 May 2015 10:19:22 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87k2wn9ket.fsf@lifelogs.com> References: <87oam08ofr.fsf@lifelogs.com> <87k2wo8kd7.fsf@lifelogs.com> <87d22g8h7d.fsf@lifelogs.com> <871tiw86ez.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430835615 17656 80.91.229.3 (5 May 2015 14:20:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 May 2015 14:20:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 05 16:20:00 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 1YpdhY-0002hr-5V for ged-emacs-devel@m.gmane.org; Tue, 05 May 2015 16:20:00 +0200 Original-Received: from localhost ([::1]:39685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpdhX-0005ow-Fx for ged-emacs-devel@m.gmane.org; Tue, 05 May 2015 10:19:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpdhL-0005or-6R for emacs-devel@gnu.org; Tue, 05 May 2015 10:19:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YpdhG-0008O5-OR for emacs-devel@gnu.org; Tue, 05 May 2015 10:19:47 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:39379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YpdhG-0008Nu-Hh for emacs-devel@gnu.org; Tue, 05 May 2015 10:19:42 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YpdhD-0002W5-Sh for emacs-devel@gnu.org; Tue, 05 May 2015 16:19:40 +0200 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 May 2015 16:19:39 +0200 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 May 2015 16:19:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 71 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net 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" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:U0JO7Zpd9x116oIKyAIRVaZhjpg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:186232 Archived-At: On Tue, 05 May 2015 07:50:14 -0400 Stefan Monnier wrote: >> Clearly, because I think it's worth annoying the user, since plain HTTP >> should be the exception. SM> "Because I like it" is not a very compelling argument in this case. That's not what I said. I just didn't think I needed to explain why a plaintext protocol is a bad choice here. There are two issues: 1) all web traffic should be encrypted by default. Unencrypted traffic is much easier to monitor, MITM, and DoS. You can find support for this stance pretty easily, e.g. 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. 2) Specifically for Emacs, several attacks (e.g. those against package signature verification that have been posted on the bugs list, like the replay attack in https://lists.gnu.org/archive/html/bug-gnu-emacs/2015-01/msg00002.html) are dramatically easier against a plaintext transfer than against an encrypted one. If the user doesn't have GnuPG installed (and we've agreed to treat that as an acceptable situation, right?), encrypting the transfer is even more crucial. It's too easy for the annoyed user to say "forget verifying signatures, I want to get my work done" so we should try to at least put some defenses around them. This user laziness is not a theoretical problem. See for example https://emacs.stackexchange.com/questions/233/how-to-proceed-on-package-el-signature-check-failure where one of the suggestions is https://emacs.stackexchange.com/a/5502 "I changed the package-check-signature value to nil and the problem was resolved." Users are not going to look into why the key was missing and contact the package author or inspect their HTTP traffic, they'll blaze ahead. So I note again that my proposal is simply to warn the user, not to block them from using plain HTTP. And, of course, they'll be able to turn off the warning if they really don't want to encrypt their package download channel. Is that really unreasonable and annoying? SM> Why? Why not just SM> (if (we-have-gnutls) ) >> 2) because I don't think this should be set in the code. It's a user choice. SM> We're talking about the expression that computes the default value of SM> a custom var. So, of course, the user can override it in the usual way. The default you propose is *code*, determined at runtime (unless the user customizes it). I think instead, *in this case*, we should always try HTTP/S first and complain when it's not available, as I said above. The user can then choose to silence all such warnings or change the default. >> 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. Please consider how many other package managers allow multiple URLs. Is there a real disadvantage to allowing a list for `package-archives' entries, especially since it degrades gracefully to the current format? Regardless of your opinion on HTTP/S, I think this is a useful feature. Ted