From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Phil Hagelberg Newsgroups: gmane.emacs.devel Subject: Re:package.el + DVCS for security and convenience (was: ELPA security) Date: Mon, 31 Dec 2012 12:06:22 -0800 Message-ID: <87ip7ing01.fsf@enigma.home.hagelb.org> References: <8738zf70ep.fsf@riseup.net>, <871uejlbm1.fsf@lifelogs.com>, <87obhmzl2f.fsf@bzg.ath.cx>, <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1356984435 26752 80.91.229.3 (31 Dec 2012 20:07:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 20:07:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 31 21:07:31 2012 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 1Tpldz-0000vn-8r for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 21:07:31 +0100 Original-Received: from localhost ([::1]:55967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tpldk-0000pV-6P for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 15:07:16 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tplda-0000of-Jb for emacs-devel@gnu.org; Mon, 31 Dec 2012 15:07:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TpldU-0002aa-QI for emacs-devel@gnu.org; Mon, 31 Dec 2012 15:07:06 -0500 Original-Received: from mail-pb0-f50.google.com ([209.85.160.50]:47831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpldU-0002aJ-IU for emacs-devel@gnu.org; Mon, 31 Dec 2012 15:07:00 -0500 Original-Received: by mail-pb0-f50.google.com with SMTP id wz7so7172638pbc.37 for ; Mon, 31 Dec 2012 12:06:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:references:user-agent:in-reply-to:date :message-id:mime-version:content-type:x-gm-message-state; bh=UgyA2A1WUAI3azMSU4Wn9xhNrDHgGm4wspuN6OPq0uw=; b=kadGGFX5Vr9eWAcX+fVVqSZLH62SvhmiRflJ78tvsE9nN66c/6K4FIoom1Pc/v44mT znbnnvKMrXF0P+u4j/R1YR6Vv7jpxb+u00q/cmRdnGO0f2COy2+zFSBAW/CX8XNO4nkD I2m0JNARg+ud/FUMeZasflwH4cgTXhVcL+Dw0LD8QxuYKOlmJ2O+6cvxHDf/ECFCxQyU olqnPS124PgtPPE57EAsI+DjZA22KdLM12M3b4C1qvePNExmBV54wREGXU7CDYbmi5Am OHXVIgbhhcTA10a4k/kZvS0KokNkpyNjI9Y7V0+CsmYTTG1YdSBErKcYdiX6kEVaMkJe Y1oA== X-Received: by 10.68.130.226 with SMTP id oh2mr87903552pbb.157.1356984419428; Mon, 31 Dec 2012 12:06:59 -0800 (PST) Original-Received: from enigma.home.hagelb.org (67-42-85-138.tukw.qwest.net. [67.42.85.138]) by mx.google.com with ESMTPS id ou3sm25349560pbb.46.2012.12.31.12.06.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Dec 2012 12:06:58 -0800 (PST) User-agent: mu4e 0.9.8.4; emacs 24.1.50.3 In-reply-to: <87sj6xg9p2.fsf_-_@lifelogs.com> X-Gm-Message-State: ALoCoQkVtmroMXU3NSmxZiwed7tfWB0nC/wHLEARm9/NyeXWidjkIjlhWXALBNcQP5d1gQoUvKsx X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.160.50 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:156040 Archived-At: Ted Zlatanov writes: > I propose to require signatures for ELPA packages and make package.el > aware of signatures Having just gone through this process for the Clojure community repository, it might be helpful for me to describe what we ended up with there. We ended up creating a new repository for the signed releases, but this had more to do with flaws in the existing repository than anything related to security. But the gist of it was that each package uploaded had to be accompanied by an .asc file that was checked at upload time against a public key that we had on file for the maintainers. The plan is to also have a repository-level key that's used to verify the fact that the given signed package was uploaded at a given time; that way were a key to be compromised it would be possible to ensure that the package was uploaded before the key was revoked. We are working on building up a web of trust within the community of Clojure library developers, but this is a long-term goal. This kind of model would probably be important to the community repositories like Marmalade and MELPA, but the GNU repository can sidestep some of this complexity because there's a central authority that everyone can trust. However, I'd suggest that rather than having GNU sign the packages directly, they could sign the keys of those maintainers who have privileges to upload. That makes revocation possible. For Clojure right now we have rudimentary checks to ensure that all the packages in a dependency tree are at least signed, but we don't yet have a mechanism to walk it to ensure that everything's signed by someone you trust or trust transitively. But IMO it's important to start collecting signatures as early as possible even if the tools to check it on the client don't exist yet; in the long run you want to minimize the number of published unverifiable packages. I don't see any benefit to using version control tools on the client side. It may make sense to use them to build the repository, but having the repository consist simply of a pile of static files on disk is a very valuable property that we shouldn't give up lightly. Adding SSL to the existing implementation would be fairly easy and has no downsides, so it should be done soon; it's low-hanging fruit that can be improved quicker than adding signatures. I would just like to add that I consider writing an OpenPGP implementation in Emacs to be a very bad idea--we simply do not have the resources to get the auditing that would be necessary to get this to a level of quality that we could trust. Using GnuPG would be both quicker to implement and result in much higher-quality code. If there are concerns that people may not use it because it's difficult to install then our efforts would be better spent on making it easier to install. I'm very glad to see movement on this front though--the current state of affairs is an improvement over everyone pulling packages in from the wiki but still has a long way to go before it's something properly trustworthy. -Phil