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 16:12:45 -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]:42495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJnlE-0002SF-Ky for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 16:13:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJnlC-0005mm-Jd for emacs-orgmode@gnu.org; Sun, 03 Jul 2016 16:12:59 -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: Bastien , Ian Barton , Arun Isaac , emacs-orgmode@gnu.org, Nicolas Goaziou Konstantin Kliakhandler writes: > Hello Robert, > > I am the OP. > > For what it is worth, the current discussion is actually precisely what I > was aiming at. I agree with your analysis of my Intended goals but > completely disagree that SHA1 alone is any sort of guarantee.. To be > precise, I don't just think that it doesn't provide much, but rather that > alone it provides none at all. This is because I have no idea who produced > a given SHA1 - whether it was Bastien, or a MITM attacker, or just someone > who compromised the server. The SHA1's are created by the git processes at the git server that you connect to. Or, in the case of a malicious source, by the malicious source appearing to be the git server. The SHA1's are reference elements used throughout git, and are primarily for integrity protection against accidents, not against attackers. Hence it's sufficient that they be maintained by the git processes. The plain vanilla git process does not include distribution of SHA1 values by an independent path, so it's not easy to verify against a trusted source for the correct values. As Achim Gratz says: >If the server or repo gets compromised, then it is game over >until someone notices that the server suddenly doesn't match up the >local clone. The most common and appropriate next step (assuming git is used for distribution) is to make use of PGP signing of tagged versions in git. This is a strong signature traceable to some release person or process. It provides strong verification and authentication for the contents of a specific tagged release. This protects against distribution server and repo compromises, but not against development process compromises. This would be a reasonable step for org-mode releases. The release process only involves a few people, and key management would not be too hard. It doesn't solve the problem for non-git distribution methods. My guess is that the ELPA users are the most exposed. Fixing that really belongs to ELPA, but if I were putting together the cyber security plan for org-mode I would call out this gap and make clear that it is a gap that can't be easily solved by org-mode. (Maybe tweaking someone more familier with ELPA to tell me how to solve it for ELPA.) Signed tags do not provide much extra protection for developers. The usual git process of using SSH keys to authenticate developers is much easier to manage than individually signed changes. It's vulnerable to all the usual attacks. Overall integrity depends upon the release testing and verification process. Signed commits can reduce these risks. Signed commits are a lot more work than the SSH key methods. I doubt that the committers have the appetite to deal with all the issues involved. R Horn