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: Package signing infrastructure suggestion (was Re: ELPA security) Date: Mon, 31 Dec 2012 17:32:24 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87y5gdzwcn.fsf@lifelogs.com> References: <8738zf70ep.fsf@riseup.net> <871uejlbm1.fsf@lifelogs.com> <87623i5tld.fsf@lifelogs.com> <87pq1q8hnn.fsf_-_@ferrier.me.uk> 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 1356993162 27315 80.91.229.3 (31 Dec 2012 22:32:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 22:32:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 31 23:32:59 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 1Tpnuk-0005Fk-SI for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 23:32:59 +0100 Original-Received: from localhost ([::1]:57357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpnuV-000058-UP for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 17:32:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpnuP-0008Ue-En for emacs-devel@gnu.org; Mon, 31 Dec 2012 17:32:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TpnuO-0005qw-3d for emacs-devel@gnu.org; Mon, 31 Dec 2012 17:32:37 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:44295) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpnuN-0005qs-TT for emacs-devel@gnu.org; Mon, 31 Dec 2012 17:32:36 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tpnub-00058p-4u for emacs-devel@gnu.org; Mon, 31 Dec 2012 23:32:49 +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 23:32:49 +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 23:32:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 67 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:V0r7OpG70vGsIIMmrAuczjShGzk= 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:156049 Archived-At: On Mon, 31 Dec 2012 13:39:40 +0000 Nic Ferrier wrote: NF> Ted Zlatanov writes: >> 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. NF> ... >> 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. NF> It sounds like you are mixing up a lot of different things. NF> A package is an artifact from a build system and that separation between NF> packages and repositories is a good thing. In my proposal, the repository is not the classical source repository that produces packages but a storage space for the ELPA packages, which is how it's used by the GNU ELPA (a branch in the Emacs Bazaar repo). I think for the ELPA it makes sense to strenghen that integration in order to achieve package verification and other useful features, like retrieving a specific verision of the ELPA repository or mirroring an ELPA repository easily. NF> A better solution is to have a standard location for signed packages, NF> perhaps a derivable HTTP or file URL. We can sign the key package with a key that's stored in Emacs itself. I was hoping not to bolt the security on top of the current HTTP mechanism but to integrate it with the DVCS better, but if you and Tom and others think it's better to piggyback on top of HTTP, I'll go along. NF> A single package could be used to collect everyone's keys. NF> When a new maintainer is added the key package would have to be NF> updated. NF> The key package could be constructed automatically from gpg key stores NF> or individual uploads of keys. Something that assures we know who NF> someone is. NF> The key package should have a unique name derived from the repository so NF> other repositories can support the same system if they wish to. NF> It's quite important, I think, that the maintenance of the key package NF> is separate from the signed packages themselves. I understand your proposal and think it makes a lot of sense. But how is it better than signed commits with Bazaar or signed tags with Git? With signed commits/tags, only one public key is needed (the repository maintainer) and it's easy to say "right here, everything in this repository is approved." There's also no need to revoke packages in this scheme, because you'd commit a revert of the earlier bad code and sign that new commit. And finally, there is no "key package" or much else special... you just use the built-in DVCS facilities. Ted