From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Bug#766395: emacs/gnus: Uses s_client to for SSL. Date: Sat, 25 Oct 2014 05:51:36 +0900 Message-ID: <87wq7pgpif.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141022193441.GA11872@roeckx.be> <87zjcnj2k6.fsf@trouble.defaultvalue.org> <87mw8mzmxj.fsf@mid.deneb.enyo.de> <20141023143702.3897e618@jabberwock.cb.piermont.com> <8761fazkx7.fsf@mid.deneb.enyo.de> <20141023145721.12ed0820@jabberwock.cb.piermont.com> <87vbnay5lf.fsf@mid.deneb.enyo.de> <20141023154223.45f2c9eb@jabberwock.cb.piermont.com> <874muuihjh.fsf@uwakimon.sk.tsukuba.ac.jp> <20141023230048.13f8234a@jabberwock.cb.piermont.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1414183926 17416 80.91.229.3 (24 Oct 2014 20:52:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2014 20:52:06 +0000 (UTC) Cc: Florian Weimer , emacs-devel@gnu.org, kurt@roeckx.be, Rob Browning , rms@gnu.org To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 24 22:51:59 2014 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 1Xhlq2-0001eW-TL for ged-emacs-devel@m.gmane.org; Fri, 24 Oct 2014 22:51:59 +0200 Original-Received: from localhost ([::1]:50459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xhlq2-00051y-J0 for ged-emacs-devel@m.gmane.org; Fri, 24 Oct 2014 16:51:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xhlpt-00051r-5v for emacs-devel@gnu.org; Fri, 24 Oct 2014 16:51:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xhlpj-00087O-FZ for emacs-devel@gnu.org; Fri, 24 Oct 2014 16:51:49 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:51130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xhlpj-00087C-5Y; Fri, 24 Oct 2014 16:51:39 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6E0001C3C60; Sat, 25 Oct 2014 05:51:36 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 55CA41A2D06; Sat, 25 Oct 2014 05:51:36 +0900 (JST) In-Reply-To: <20141023230048.13f8234a@jabberwock.cb.piermont.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:175792 Archived-At: Perry E. Metzger writes: > > Wrong. Many people these days are using free software in corporate > > environments where they need to get the new versions vetted by > > corporate security. > > I've been doing security in such environments for about the past 20 > years. I'm plenty familiar with them. The sensitive users, > like banks, upgrade quite quickly. But you're defining "sensitive" in terms of security, and that's the wrong definition -- those sensitive users are already doing what you advocate and don't need encouragement to upgrade their servers and so on.[1] It's security-insensitive users who would be inconvenienced, and either turn to an alternative which still supports the vulnerable protocol or turn off security entirely. Sad to say, not all companies with strict policies about what *you* can install are quick to upgrade what *they* have installed. Footnotes: [1] It's true that these users *need* the option to turn off the less secure protocol so it doesn't get used inadvertantly, and it's probably desirable that it be off by default.