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: package.el + DVCS for security and convenience Date: Wed, 09 Jan 2013 11:37:15 +0900 Message-ID: <87lic39j50.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8738zf70ep.fsf@riseup.net> <20121222141742.7494b429fe36e5ccef50cf6f@gmail.com> <87d2y2w9j5.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqwas0gr.fsf@bzg.ath.cx> <87d2y2p6d7.fsf@bzg.ath.cx> <87sj6xg9p2.fsf_-_@lifelogs.com> <87k3s78hsc.fsf@lifelogs.com> <87ehi65uv4.fsf@lifelogs.com> <87hamxndc7.fsf@lifelogs.com> <87y5g8n4y1.fsf@lifelogs.com> <87lic8b9ai.fsf@uwakimon.sk.tsukuba.ac.jp> <87zk0mktir.fsf@lifelogs.com> <87bod1bvhg.fsf@uwakimon.sk.tsukuba.ac.jp> <877gnpkq1u.fsf@lifelogs.com> <87y5g4a1ob.fsf@uwakimon.sk.tsukuba.ac.jp> <87sj6bg0zj.fsf@lifelogs.com> <87obgza7d7.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1357699050 31247 80.91.229.3 (9 Jan 2013 02:37:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2013 02:37:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 09 03:37:46 2013 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 1TslXv-0004PJ-F4 for ged-emacs-devel@m.gmane.org; Wed, 09 Jan 2013 03:37:39 +0100 Original-Received: from localhost ([::1]:53444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TslXe-0003NE-Vf for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2013 21:37:22 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TslXc-0003MB-GY for emacs-devel@gnu.org; Tue, 08 Jan 2013 21:37:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TslXb-0007Z4-7A for emacs-devel@gnu.org; Tue, 08 Jan 2013 21:37:20 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:37643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TslXa-0007Xw-N0 for emacs-devel@gnu.org; Tue, 08 Jan 2013 21:37:19 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 904E39708F8; Wed, 9 Jan 2013 11:37:15 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 53CCA11F808; Wed, 9 Jan 2013 11:37:15 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:156171 Archived-At: Stefan Monnier writes: > >> Stefan has confirmed (I believe) the GNU ELPA maintainers will use a > >> single "GNU ELPA" key to sign package releases. > > Have you given up on having every commit signed? > > I haven't even tried to sign a single Bzr commit. That is the way a lot of projects do it. It's not zero-cost (indirectly evidenced by the fact that such projects typically have a lot of people paid directly or indirectly to work on them). All that the proposed signing system does is eliminate man-in-the- middle attacks on the transport of packaged Lisp. This is worth doing, because apparently it's trivial to suborn parts of the DNS, and because it makes it possible to authenticate mirrors, all at low cost to the maintainers and users. Nevertheless, it does nothing to make GNU ELPA more secure than it currently is against attacks on the code in the repo itself or on the release process. In the long run, is that good enough for Emacs? > Hell, I use GPG rarely enough, that I typically end up having to > create a new key because I can't remember the password I used for > the last one. Me too. ;-) I'm going to start learning, though. > And I worry about what happens if/when we restructure the repository > (currently we have a single Bzr branch with all packages in it (except > for Org), but we'll probably want to move to a setup where more packages > have their own branches, also we may move from Bzr to something else). That is indeed potentially costly. However, if you're not going to consider eventually bearing such costs, my position is that you should seriously consider doing nothing, since the system that will be implemented provides very little assurance that the code is "safe". Yet many naive users will see the signatures and assume they mean something they don't. > And I'm not sure what would be the gain with such signatures: I'm > shocked to hear people would trust me, since I don't trust myself (and > some (former?) friends of mine know I'm not trustworthy). You write as if you think my trust in you is absolute. It's not; I simply would trust your code more than I would some other folks'. Among other things, it's well-organized and easy to read, which means I can review it myself. That is the whole point I was trying to make by writing that I would trust you -- trust is relative, and a function of people as well as systems. And I put little weight on your statement that you're shocked; people are often poor judges of their own worth. > [ For the record, I work in the context of certified programming, > where you don't want to trust people at all, and instead expect > them to give you a formal proof that their code is safe. ] I don't understand the relevance of that comment. Since you have disclaimed the intent to do security reviews, you obviously can't possibly be providing formal proofs for code safety. Nothing is left except to recognize that in downloading and using packages (and Emacs itself) users are implicitly trusting contributors who are many, do not have easily verified identities, and in some cases are effectively anonymous. Of course we don't want to trust, but there is no alternative to trusting somebody. In the current state, we are forced to trust everybody to the same degree. > > You are highly skilled at missing the point. > Let's try to stay clear of such ad-hominem, please. It's not "argument ad hominem", but since the current plan is to restrict signatures to authenticating provenance, it has become irrelevant. I retract the statement.