From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: ELPA security Date: Mon, 31 Dec 2012 06:50:06 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87623i5tld.fsf@lifelogs.com> References: <8738zf70ep.fsf@riseup.net> <871uejlbm1.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1356954637 26634 80.91.229.3 (31 Dec 2012 11:50:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 11:50:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 31 12:50:53 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 1TpdtL-0006y7-Ml for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 12:50:51 +0100 Original-Received: from localhost ([::1]:50665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tpdt6-0001Im-UZ for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 06:50:36 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tpdt3-0001Ht-K5 for emacs-devel@gnu.org; Mon, 31 Dec 2012 06:50:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tpdsz-0000w0-Fj for emacs-devel@gnu.org; Mon, 31 Dec 2012 06:50:33 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:40422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tpdsz-0000vr-9f for emacs-devel@gnu.org; Mon, 31 Dec 2012 06:50:29 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tpdt9-0006no-P4 for emacs-devel@gnu.org; Mon, 31 Dec 2012 12:50:39 +0100 Original-Received: from c-65-96-148-157.hsd1.ma.comcast.net ([65.96.148.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Dec 2012 12:50:39 +0100 Original-Received: from tzz by c-65-96-148-157.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 31 Dec 2012 12:50:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 49 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-65-96-148-157.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:KBXYrLSgJW2AFuCCCv9OUgbWjn8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:156022 Archived-At: On Wed, 26 Dec 2012 09:32:44 -0800 Paul Nathan wrote: PN> - In general, GNU is trusted (after all, we download our emacs from the PN> GNU). This would imply to me that the GNU can GPG sign packages with a PN> private/public key (Perhaps the precursor to this is emacs having a gpg PN> implementation included). Hmm. So maybe there can be signed checkpoint commits to a global ChangeLog file that validate all the commits up to that commit? Then package.el would pull that commit from the ELPA DVCS repository and ignore all later, unconfirmed commits? That seems very workable for the maintainers and for package.el: 1. add DVCS support to package.el, supporting Git and Bazaar, with the notion of "pull packages from repo X at tag/commit Y" in addition to the current "pull packages from URLs". The VC package has to be involved here, instead of writing custom code. 2. when the user requests it and we can support it, we verify that Y is signed with the ELPA maintainer key. This will be optional, but for the GNU ELPA we'll check by default and warn if the verification fails. The VC package may be involved here or it could be done in package.el; the underlying verification will be done by an external tool at first and may be implemented internally in Emacs later. 3. we may need a way to revoke a signed commit. Perhaps it can simply be a revert of the previously committed "bad" code, followed by another commit, instead of a full revocation process. 4. I don't think we should provide this mechanism without a DVCS that supports signing a tag or a commit. In other words, let's not try to bolt it on top of the current HTTP ELPA structure. PN> - Then perhaps other repositories, such as marmalade could also sign their PN> packages, and users could choose to trust that signature or not. PN> - Of course, this is analogous to the Debian/Launchpad/PPA approach, which PN> has worked excellently for me and others. It may require quite a great deal PN> of infrastructure work which I am entirely unfamiliar with. I think the proposal above minimizes new infrastructure. It moves the verification and signing burden to the ELPA (e.g. the GNU ELPA) maintainers, which I think is the right place. The new DVCS repo pointers in package.el can coexist with the current HTTP pointers for a nice gradual transition. If this sounds acceptable I will start on a POC. Ted