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 06:47:37 +0900 Message-ID: <87r3xxgmx2.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> <87wq7pgpif.fsf@uwakimon.sk.tsukuba.ac.jp> <20141024171421.78720abe@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 1414187295 6099 80.91.229.3 (24 Oct 2014 21:48:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2014 21:48:15 +0000 (UTC) Cc: Florian Weimer , rms@gnu.org, kurt@roeckx.be, Rob Browning , emacs-devel@gnu.org To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 24 23:48:08 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 1XhmiN-0004ua-B8 for ged-emacs-devel@m.gmane.org; Fri, 24 Oct 2014 23:48:07 +0200 Original-Received: from localhost ([::1]:50928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhmiM-0006gA-UZ for ged-emacs-devel@m.gmane.org; Fri, 24 Oct 2014 17:48:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xhmi3-0006fq-86 for emacs-devel@gnu.org; Fri, 24 Oct 2014 17:47:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xhmhv-0004BM-O3 for emacs-devel@gnu.org; Fri, 24 Oct 2014 17:47:47 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:51678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xhmhv-0004BC-E4; Fri, 24 Oct 2014 17:47: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 40D841C3D65; Sat, 25 Oct 2014 06:47:37 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 32E241A2D06; Sat, 25 Oct 2014 06:47:37 +0900 (JST) In-Reply-To: <20141024171421.78720abe@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:175796 Archived-At: Perry E. Metzger writes: > When you study the failures in enough real world deployed systems, > even when used by trained personnel, you lose your belief that it > is okay to provide knobs to the users that they don't understand very > well. Really the only safe system follows "there should be only one > mode, and it should be secure". I heard you the first time. What your discussion ignores is that that's already a moot point, especially in free software. The insecure alternative exists, is installed, and will be used in preference to an upgrade with "one mode and that mode is secure" if the inconvenience of security is great enough. It's possible that the inconvenience is small. Your anecdote about P25 radios suggests that in that case in fact it was, but that can only be determined by finding out whether organizations different in many ways are the same in that dimension. On the other hand, it is a fact that people have died (and to this day are dying in Japan) because of lack of compatibility between communication systems among cooperating organizations such as fire and police. It's possible that fallback-to-compatible capability did matter and still does matter. I'm not going to attempt to deny the importance of security, the lack of information and training in use of optional security features among users, or the rapid escalation of frequency and power of attacks. Nevertheless, advocating extreme security policy is unlikely to achieve the goal of extreme security in the current environment, and I believe that a more balanced approach can do better.