From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Horn Subject: Re: Why no secure code retrieval Date: Sun, 03 Jul 2016 20:17:13 -0400 Message-ID: References: <87mvm4sewl.fsf@systemreboot.net> <87y45m28vp.fsf@saiph.selenimh> <87lh1k5dj1.fsf@free.fr> <20160702165130.GA1401@scamper2.bantercat.co.uk> <87eg7bnqob.fsf@free.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJrZg-00077o-QH for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 20:17:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJrZf-0007T9-Fl for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 20:17:20 -0400 In-reply-to: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Konstantin Kliakhandler Cc: Arun Isaac , Bastien , Stromeko@nexgo.de, emacs-orgmode@gnu.org, Nicolas Goaziou , Ian Barton Konstantin Kliakhandler writes: > > Sufficient for what? I believe we were discussing security (that was my > intention at least, and so did your previous email seem to indicate). And > if this is the case, you have just contradicted yourself. I apologize for > pointing it out so directly, and also if I misunderstood you. Sufficient for current risk mitigation in my opinion. You disagree. We both agree that signed tags would be better. Choices are based on an evaluation of risks, threats, and mitigation costs. Emacs has had very few security vulnerabilities discovered. There are only 18 CVE since 2000. None of these allowed priviledge escalation, and the two most severe required local user assistance. So org-mode is not in a high risk location. That means that I look for very low cost steps, i.e., very simple easy changes. Signing tags falls into that category because it only affects a few people and is not particularly difficult to manage for very small groups. Another step that I would take is to establish and publish the planned security processes. These should be established and understood well before any event takes place. Taking adhoc reactive steps in an emergency often causes more problems. > I believe that these days elpa is accessed by default via https and that > archives are signed, though please correct me here. Assuming it is the > case, there isn't much one can do beyond the currently suggested steps, I > think. > I took a quick look inside package.el and it is still incomplete. It's also got a big todo list, so I expect this to change with subsequent releases. As of Emacs 24.3 ELPA did not have package signatures. Emacs 24.5 has package signatures, but no way for the user to verify that what is installed matches the signature. As of 24.5, the default behavior in package.el is: - package signatures are optional - package signatures are only checked to confirm that the tar file that is downloaded matches the signature. There is no tooling for subsequent verifications. - invalid signatures are ignored by default - missing signatures are ignored by default - package.el has dependencies on programs external to emacs. If these dependencies are not met, it reverts to default behavior. This is clearly better than 24.3. Again, in terms of risk/cost/mitigation evaluation I would have the tool that creates the ELPA package for org-mode also create a signature. It might do that already. Package.el does not indicate which packages are signed. I would let the folks taking care of ELPA deal with the rest in later releases. Use of https for most ELPA repositories does protect against in transit content corruption, but not necessarily much else. Looking at elpa.gnu.org I notice: - Their certificate expired today and has not been updated, oops - They use Let's Encrypt as signing authority. This means that the certificate verifies that whoever responds to the domain name http port controls the TLS certificate and web content. That's enough for many purposes, but it doesn't mean much in terms of server security. In transit MITM is a minor threat for software distribution. I've only detected MITM activity in public locations once in the real world. (I was thrilled. It's a really rare event.) It was in a very high threat location (Washington DC area, a public wifi). The big MITM threat is the dangers from malicious javascript insertion into unprotected browser activity. R Horn rjhorn@alum.mit.edu