From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: Enforcing TLS for GNU ELPA Date: Tue, 20 Oct 2020 12:05:34 +0300 Message-ID: References: <20201019221020.GD1842@odonien.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12862"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/+ (1036f0e) (2020-10-18) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 20 11:06:37 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUnbJ-0003Fx-CN for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Oct 2020 11:06:37 +0200 Original-Received: from localhost ([::1]:33054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUnbI-0008Em-Dr for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Oct 2020 05:06:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUnad-0007cW-Au for emacs-devel@gnu.org; Tue, 20 Oct 2020 05:05:55 -0400 Original-Received: from static.rcdrun.com ([95.85.24.50]:37945) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUnaa-0003qN-Jp for emacs-devel@gnu.org; Tue, 20 Oct 2020 05:05:54 -0400 Original-Received: from localhost ([::ffff:41.202.241.51]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002A0BF2.000000005F8EA86E.00002448; Tue, 20 Oct 2020 09:05:49 +0000 Content-Disposition: inline In-Reply-To: <20201019221020.GD1842@odonien.localdomain> Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/20 03:17:37 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258174 Archived-At: * Vasilij Schneidermann [2020-10-20 01:11]: > Some time ago I've contributed a change to a certain package > repository's webserver setup that responds to http:// requests with a > 301 redirect to the https:// version. Should the same be done for GNU > ELPA? Why/why not? > > Some data points for the "why not" faction I've discovered after that > change: > > - There's still Windows users who do not have an installation with the > gnutls libraries, despite the strong suggestion to download it for the > full experience. I would say, sorry, there is no access to Emacs supported packages. If they want without signing, they can find out configuration option. > - Emacs versions below 26.1 are affected by a HTTPS proxy bug [1] that > makes life in corporate environments hard. I would say sorry for that, and would push security. Administrator in corporate environment can provide all allowed or by corporation approved packages to each user, either by making general settings on a single computer, or by entering defaults in /etc/skel/.emacs.d/elpa/you-name-it Majority of GNU/Linux distributions already have Emacs packages inside of distribution. Some of them have more than few hundred packages. In that sense, corporate environment is not a problem as BOFH can do it for its users. > - The initializer of `package-archives` already generates the > appropriate URL, so this will affect people who have redefined that > variable and break their setup for no reason. There is reason of security, it could be announced in new Emacs version. Provided it is done.