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: Tue, 08 Jan 2013 11:20:16 +0900 Message-ID: <87wqvoa00v.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> <87lic8b9ai.fsf@uwakimon.sk.tsukuba.ac.jp> <87zk0mktir.fsf@lifelogs.com> <87bod1bvhg.fsf@uwakimon.sk.tsukuba.ac.jp> <877gnpkq1u.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 1357611626 4364 80.91.229.3 (8 Jan 2013 02:20:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2013 02:20:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 08 03:20:43 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 1TsOnw-0002fv-Ne for ged-emacs-devel@m.gmane.org; Tue, 08 Jan 2013 03:20:40 +0100 Original-Received: from localhost ([::1]:53009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsOnh-0001BT-3H for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2013 21:20:25 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsOnc-00019T-Ll for emacs-devel@gnu.org; Mon, 07 Jan 2013 21:20:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsOnb-0006kk-4K for emacs-devel@gnu.org; Mon, 07 Jan 2013 21:20:20 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:47934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsOna-0006jl-J3 for emacs-devel@gnu.org; Mon, 07 Jan 2013 21:20:19 -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 7A1F39708CE for ; Tue, 8 Jan 2013 11:20:16 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 403791A30DD; Tue, 8 Jan 2013 11:20:16 +0900 (JST) In-Reply-To: <877gnpkq1u.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:156129 Archived-At: Ted Zlatanov writes: > On Mon, 07 Jan 2013 11:03:07 +0900 "Stephen J. Turnbull" wrote: > > SJT> Ted Zlatanov writes: > SJT> I have no idea what you think you're proposing. OK, time for me to spit out what *I*'ve implicitly been thinking should be the process. 0. Emacs should do something about this, and soon. Rationale: As somebody posted earlier [my apologies for failure to cite correctly], it's important to do something as soon as possible, because resistance to bureacracy etc builds up fast. 1. Mission creep should be avoided. Rationale: For the same reason, it's important to do what you do right the first time. Resistance to change builds up quickly, and is stronger if the original effort was not very successful. 2. The first mission, cheap to implement, is to authenticate the packages that are at GNU ELPA. Rationale: It's cheap, and everybody (except XEmacs, mea maxima culpa) does it so people are familiar with it. 3. The authentication should be done via a list of authorized signatures, not a single "GNU ELPA Maintainer" (GEM) signature. Rationale: If a personal signature gets compromised, it's much less costly to revoke. Some users may wish to assign different levels of trust to different signatures. Eg, if Stefan were maintaining a package, I would not hesitate to put the highest level of trust on his signature. I wouldn't feel the same way about a new package contributor, nor would I feel the same way about Stefan signing a package he had never contributed to, and certainly not a GNU ELPA Maintainer signature masking a group of volunteers most of whom I don't know. YMMV, this is my rationale. ;-) Exception: There could be a GNU ELPA bot that does nothing except certify that the package is exactly as distributed by GNU ELPA, it would have a GEM signature. Probably not worth it, though, as it has little extra value to users but would be an obvious attack vector. 4. Package maintainers (PMs) should be considered leading candidates for signing their own packages as pushed to GNU ELPA. PMs should use a specific key exclusively for signing GNU ELPA packages for authentication purposes. Rationale: *Any* such PM signature authenticates the package as having been contributed to GNU ELPA. Some users might assign more trust to individual PM signatures, but that's neither recommended nor deprecated by the GNU ELPA. 5. The next mission is to develop security criteria for reviews. This will be an ongoing process, with basics ("don't load random libraries from the default directory") coming first, and more extensive reviews ("how could this hook be abused?") postponed until later. Rationale: Without a definition of what is being reviewed, users have no basis for assigning trust. Graded review process is important so that in the early stages GNU ELPA can proclaim high quality review *as far as it goes* even though the standard is weak. As reviewer resources become available, the standard can be strengthened without loss of quality. 6. Code that has been security reviewed would get a separate "SR" signature (ie, personal to the reviewer and a different key from either the GEM key(s) or the PM keys). Rationale: The signature is separate so that authentication signatures can be implemented first. Rationale for personal keys is as for PM signatures. Also, I personally would put less trust in a security review by the author of the code reviewed (from introspecting my own blind spots). The key needs to be separate from the GEM and PM keys to make automation of checking for security review straightforward. (POC. There may be better ways of doing this, equally secure and straightforward for users, while less burdensome for reviewers.) Caveat lector: Incomplete and not all that carefully thought-out. Steve