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: Tue, 08 Jan 2013 10:15:12 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87sj6bg0zj.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> <87zk0mktir.fsf@lifelogs.com> <87bod1bvhg.fsf@uwakimon.sk.tsukuba.ac.jp> <877gnpkq1u.fsf@lifelogs.com> <87y5g4a1ob.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 1357658131 8713 80.91.229.3 (8 Jan 2013 15:15:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2013 15:15:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 08 16:15:48 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 1Tsau4-00080H-6f for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2013 16:15:48 +0100 Original-Received: from localhost ([::1]:36227 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tsato-0006rs-IP for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2013 10:15:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tsatk-0006rc-RB for emacs-devel@gnu.org; Tue, 08 Jan 2013 10:15:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tsatj-0000xA-Hu for emacs-devel@gnu.org; Tue, 08 Jan 2013 10:15:28 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:44406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tsatj-0000x5-7n for emacs-devel@gnu.org; Tue, 08 Jan 2013 10:15:27 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Tsatw-0007t9-HA for emacs-devel@gnu.org; Tue, 08 Jan 2013 16:15:40 +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 ; Tue, 08 Jan 2013 16:15:40 +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 ; Tue, 08 Jan 2013 16:15:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 93 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:8ZLCghGa/bVVB9VC9MsCeJ8giMs= 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:156147 Archived-At: On Tue, 08 Jan 2013 10:44:36 +0900 "Stephen J. Turnbull" wrote: >> On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" wrote: SJT> Ted Zlatanov writes: >> The alternative is to say "trust this code, though we don't know >> what it is." SJT> Your use of the unique quantifier is once again inappropriate. "We" SJT> does not have to be an undifferentiated blob; it can be SJT> personalized. To an Emacs user, the GNU ELPA is a package archive, not a personality bazaar. Our view on emacs-devel is very different and colors our thinking. So "we" reflects us, the Emacs developers, of which the GNU ELPA maintainers are a subset. SJT> You could, for example, have each volunteer provide a separate SJT> signature as they review the code. More reviews, more trust -- maybe, SJT> unless more reviews means each one is less thorough. Identification SJT> of the reviewer means trust can be a function of the reviewer. SJT> Authors don't make the best reviewers, but they do know the code, and SJT> an author signature is a certificate of authenticity. I explained that authors are much easier to compromise than maintainers. Stefan has confirmed (I believe) the GNU ELPA maintainers will use a single "GNU ELPA" key to sign package releases. He has also stated we'll use signatures to indicate provenance, not security reviews. Since I won't argue that point further, I've snipped your thoughtful replies on the topic of security reviews, except where I could clearly win the argument ;) SJT> If you actually do reasonably thorough reviews, though, you will SJT> end up with a large backlog of pending commits unless you have a SJT> lot of volunteers. I was planning to outsource it to some Russians. They are very thorough, I know the gang leader, er, I mean the project manager, personally. SJT> (Authors will have to rework features rejected for security of SJT> implementation reasons, and it would be quite painful to have a SJT> whole feature rejected for security reasons). The authors are free not to host their packages in the GNU ELPA, if they don't want to worry about security concerns. Even without security reviews, I think that should be the case, and the GNU ELPA maintainers should be free to reject packages on that basis. SJT> Nor do I see why reviewing Emacs Lisp code is *much* easier. IMHO suspicious and malicious code is more easily visible in Emacs Lisp. SJT> AFAIK you're not currently a GNU ELPA maintainer? I have the access. SJT> 0. Emacs should do something about this, and soon. SJT> 1. Mission creep should be avoided. SJT> 2. The first mission, cheap to implement, is to authenticate the SJT> packages that are at GNU ELPA. I agree. SJT> 3. The authentication should be done via a list of authorized SJT> signatures, not a single "GNU ELPA Maintainer" (GEM) signature. SJT> 4. Package maintainers (PMs) should be considered leading candidates SJT> for signing their own packages as pushed to GNU ELPA. PMs should SJT> use a specific key exclusively for signing GNU ELPA packages for SJT> authentication purposes. I think, at least for now, Stefan has decided to use a single signature. SJT> 5. The next mission is to develop security criteria for reviews. SJT> This will be an ongoing process, with basics ("don't load random SJT> libraries from the default directory") coming first, and more SJT> extensive reviews ("how could this hook be abused?") postponed SJT> until later. SJT> 6. Code that has been security reviewed would get a separate "SR" SJT> signature (ie, personal to the reviewer and a different key from SJT> either the GEM key(s) or the PM keys). I think that's a good plan, and can coexist with the more urgent need to sign the package to indicate provenance. I propose security signatures also live in `archive-contents', as Yet Another Vector Element, in an alist (reviewer . signature) format. Ted