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.el + DVCS for security and convenience Date: Sun, 06 Jan 2013 14:20:44 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zk0mktir.fsf@lifelogs.com> 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> <87lic8b9ai.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1357500068 24299 80.91.229.3 (6 Jan 2013 19:21:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Jan 2013 19:21:08 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 06 20:21:26 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 1Trvme-00035K-LJ for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2013 20:21:24 +0100 Original-Received: from localhost ([::1]:51599 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrvmP-0001Hb-75 for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2013 14:21:09 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrvmM-0001HS-3h for emacs-devel@gnu.org; Sun, 06 Jan 2013 14:21:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TrvmJ-0003k6-Md for emacs-devel@gnu.org; Sun, 06 Jan 2013 14:21:06 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:57000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrvmJ-0003jx-Fp for emacs-devel@gnu.org; Sun, 06 Jan 2013 14:21:03 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TrvmV-0002v5-DW for emacs-devel@gnu.org; Sun, 06 Jan 2013 20:21:15 +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 ; Sun, 06 Jan 2013 20:21:15 +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 ; Sun, 06 Jan 2013 20:21:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 56 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:72SXeHLPwFo/ih4n62LpMGSWc3U= 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:156099 Archived-At: On Sat, 05 Jan 2013 12:25:41 +0900 "Stephen J. Turnbull" wrote: SJT> 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. SJT> I think that's a lot uglier, and will force people to use special SJT> tools to manipulate non-Emacs structures conveniently (ie, the file SJT> system). (N.B. I wrote "convenient", not "possible".) OTOH, the raw SJT> content of archive-contents is rarely of interest to users, and the SJT> only software that knows how to manipulate archive-contents is Emacs, SJT> anyway. Write a mode to display archive-contents, suppressing SJT> signatures by default, and you're done AFAICS. I'm OK with either approach, but feel that modifying and re-signing `archive-contents' every time any file in the GNU ELPA changes is awkward and not as easy. In addition, it would make it hard to distribute a subset of the GNU ELPA (e.g. a single package from it) if there was a global registry of signatures. >> I think it's better to have the GNU ELPA maintainers sign package >> releases, not to delegate that to the authors. SJT> I think that's a bad idea. The responsibility is with the authors in SJT> the first place; you're suggesting that it be delegated to the ELPA SJT> maintainers. All the ELPA maintainers can do is testify that they SJT> built the package from sources in the repository. Unless the SJT> repository contains properly signed commits, that's not saying much. SJT> Even then, for users it's a matter of indirect trust. So for it SJT> actually to be useful to security-conscious users, the ELPA SJT> maintainers would have to vette the package authors -- *all* SJT> committers. SJT> It's really not that much work, and it's work that can and should be SJT> decentralized. I'm actually suggesting that the GNU ELPA maintainers (note the "GNU ELPA" part here, this is not any ELPA maintainer) should review and sign *every* commit to the GNU ELPA. I feel this is an essential part of building trust in the GNU ELPA (which started this discussion, and I feel has been ignored as usual in favor of the technical discussion). The alternative you propose is to trust many authors, which makes it more likely that an author will be an attack vector, either through a compromise of their own key, or by theft of identity, or because the author was an attacker from the beginning. I'd rather limit the number of trusted keys to just a few. Ted