From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nic Ferrier Newsgroups: gmane.emacs.devel Subject: Package signing infrastructure suggestion (was Re: ELPA security) Date: Mon, 31 Dec 2012 13:39:40 +0000 Message-ID: <87pq1q8hnn.fsf_-_@ferrier.me.uk> References: <8738zf70ep.fsf@riseup.net> <871uejlbm1.fsf@lifelogs.com> <87623i5tld.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1356961229 12235 80.91.229.3 (31 Dec 2012 13:40:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 13:40:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 31 14:40:45 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 1Tpfbg-0005hL-DA for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 14:40:44 +0100 Original-Received: from localhost ([::1]:43106 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpfbR-0001Xn-22 for ged-emacs-devel@m.gmane.org; Mon, 31 Dec 2012 08:40:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:38238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpfbN-0001Xi-FH for emacs-devel@gnu.org; Mon, 31 Dec 2012 08:40:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TpfbK-00034V-PW for emacs-devel@gnu.org; Mon, 31 Dec 2012 08:40:25 -0500 Original-Received: from static.17.66.46.78.clients.your-server.de ([78.46.66.17]:50772 helo=po1.ferrier.me.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TpfbK-00034O-Ib for emacs-devel@gnu.org; Mon, 31 Dec 2012 08:40:22 -0500 Original-Received: from nferrier (140.35.155.90.in-addr.arpa [90.155.35.140]) by po1.ferrier.me.uk (Postfix) with ESMTP id E050DAC00E2; Mon, 31 Dec 2012 14:42:59 +0100 (CET) Original-Received: from nferrier (localhost [127.0.0.1]) by nferrier (Postfix) with ESMTP id E21F51600B7; Mon, 31 Dec 2012 13:39:40 +0000 (GMT) In-Reply-To: <87623i5tld.fsf@lifelogs.com> (Ted Zlatanov's message of "Mon, 31 Dec 2012 06:50:06 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 78.46.66.17 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:156028 Archived-At: 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. ... > 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. It sounds like you are mixing up a lot of different things. A package is an artifact from a build system and that separation between packages and repositories is a good thing. A better solution is to have a standard location for signed packages, perhaps a derivable HTTP or file URL. A single package could be used to collect everyone's keys. When a new maintainer is added the key package would have to be updated. The key package could be constructed automatically from gpg key stores or individual uploads of keys. Something that assures we know who someone is. The key package should have a unique name derived from the repository so other repositories can support the same system if they wish to. It's quite important, I think, that the maintenance of the key package is separate from the signed packages themselves. Nic Ferrier Elnode, Marmalade, TeamChat.net