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: Sat, 05 Jan 2013 12:25:41 +0900 Message-ID: <87lic8b9ai.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <87k3s78hsc.fsf@lifelogs.com> <87ehi65uv4.fsf@lifelogs.com> <87hamxndc7.fsf@lifelogs.com> <87y5g8n4y1.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1357356349 26173 80.91.229.3 (5 Jan 2013 03:25:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2013 03:25:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 04:26:06 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 1TrKOa-0002b4-PA for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2013 04:26:04 +0100 Original-Received: from localhost ([::1]:54957 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrKOL-0007rn-GY for ged-emacs-devel@m.gmane.org; Fri, 04 Jan 2013 22:25:49 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrKOI-0007rX-HF for emacs-devel@gnu.org; Fri, 04 Jan 2013 22:25:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TrKOH-0007nZ-Ct for emacs-devel@gnu.org; Fri, 04 Jan 2013 22:25:46 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:56778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrKOG-0007mq-T2 for emacs-devel@gnu.org; Fri, 04 Jan 2013 22:25:45 -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 BCFAE97075D for ; Sat, 5 Jan 2013 12:25:41 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 818FC1A3222; Sat, 5 Jan 2013 12:25:41 +0900 (JST) In-Reply-To: <87y5g8n4y1.fsf@lifelogs.com> 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:156088 Archived-At: Ted Zlatanov writes: > On Fri, 04 Jan 2013 13:11:09 -0500 Stefan Monnier wrote: > > SM> The signatures should be added to the `archive-contents' file. > > I think `archive-contents' should contain just the keys allowed to sign > the package, not the signatures whole. Otherwise, for multi-file > packages, the file could get large and the format could be awkward. To > support both single-file and multi-file packages, I propose a X.sig > signature file for each file X in the package directory hierarchy. I think that's a lot uglier, and will force people to use special tools to manipulate non-Emacs structures conveniently (ie, the file system). (N.B. I wrote "convenient", not "possible".) OTOH, the raw content of archive-contents is rarely of interest to users, and the only software that knows how to manipulate archive-contents is Emacs, anyway. Write a mode to display archive-contents, suppressing signatures by default, and you're done AFAICS. > I think it's better to have the GNU ELPA maintainers sign package > releases, not to delegate that to the authors. I think that's a bad idea. The responsibility is with the authors in the first place; you're suggesting that it be delegated to the ELPA maintainers. All the ELPA maintainers can do is testify that they built the package from sources in the repository. Unless the repository contains properly signed commits, that's not saying much. Even then, for users it's a matter of indirect trust. So for it actually to be useful to security-conscious users, the ELPA maintainers would have to vette the package authors -- *all* committers. It's really not that much work, and it's work that can and should be decentralized.