From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Bug#766395: emacs/gnus: Uses s_client to for SSL. Date: Tue, 28 Oct 2014 12:20:06 -0400 Message-ID: <20141028122006.69384f7c@jabberwock.cb.piermont.com> 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> <87r3xxgmx2.fsf@uwakimon.sk.tsukuba.ac.jp> <20141024204202.276dbb1f@jabberwock.cb.piermont.com> <8738a95t6b.fsf@uwakimon.sk.tsukuba.ac.jp> <20141027153954.08930677@jabberwock.cb.piermont.com> <87lho04qvn.fsf@uwakimon.sk.tsukuba.ac.jp> <20141028111903.199d44ab@jabberwock.cb.piermont.com> <87tx2o43an.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1414513221 18704 80.91.229.3 (28 Oct 2014 16:20:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2014 16:20:21 +0000 (UTC) Cc: rms@gnu.org, kurt@roeckx.be, emacs-devel@gnu.org, Stefan Monnier , "Stephen J. Turnbull" , Rob Browning To: Florian Weimer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 28 17:20:16 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 1Xj9VF-0007FU-KY for ged-emacs-devel@m.gmane.org; Tue, 28 Oct 2014 17:20:13 +0100 Original-Received: from localhost ([::1]:40250 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xj9VF-0006ME-6Y for ged-emacs-devel@m.gmane.org; Tue, 28 Oct 2014 12:20:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xj9VB-0006Kk-Cq for emacs-devel@gnu.org; Tue, 28 Oct 2014 12:20:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xj9V9-000263-7n for emacs-devel@gnu.org; Tue, 28 Oct 2014 12:20:09 -0400 Original-Received: from hacklheber.piermont.com ([2001:470:30:84:e276:63ff:fe62:3400]:59913) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xj9V9-00025r-4G; Tue, 28 Oct 2014 12:20:07 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 918121432; Tue, 28 Oct 2014 12:20:06 -0400 (EDT) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 4C5252DE546; Tue, 28 Oct 2014 12:20:06 -0400 (EDT) In-Reply-To: <87tx2o43an.fsf@mid.deneb.enyo.de> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-apple-darwin14.0.0) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 2001:470:30:84:e276:63ff:fe62:3400 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:175928 Archived-At: On Tue, 28 Oct 2014 16:33:36 +0100 Florian Weimer wrote: > * Perry E. Metzger: >=20 > > The trick is to make sure it isn't used as an instrument to > > prevent ordinary people from booting software of their choice, > > but rather is used as an instrument to assure that when they boot > > the software of their choice, they're actually getting that and > > not malware. >=20 > None of the existing boot verification technologies provides this. Agreed. That said, it is important not to throw the idea out entirely -- don't dump the baby with the bathwater. > It's also difficult to reconcile this with full user autonomy=E2=80=94if = the > user can load previously untrusted key material (and especially if > this is an expected step during installation of a free operating > system), the firmware can no longer warn about malicious keys and > malicious software (because the user has replaced the trust root). The user could, however, be in charge of what trusted roots they accept/load into the firmware, or could hand-enter the hash of the software they are willing to load. This does not appreciably reduce security provided it has to be done with physical access to the machine and is properly designed. (I'm unwilling to produce such a design on the fly without thinking about it hard.) My only point was that there are legitimate reasons to want to make sure you're only loading the code you're expecting to load. Many of the sorts of technologies being discussed are actually of use. Heck, Debian signs all their packages at this point to assure non-tampering -- there is clearly a legitimate use in using signatures to make sure you're getting what you want. The only issue is, as you note, that many such systems (see iOS for example) also prevent you from getting things you might want, which is distinct from using such systems to assure that you get only what you wanted. --=20 Perry E. Metzger perry@piermont.com