From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: ELPA security Date: Sat, 05 Jan 2013 17:46:19 +0100 Organization: Linux Private Site Message-ID: <87k3rrr31g.fsf@Rainer.invalid> References: <8738zf70ep.fsf@riseup.net> <871uejlbm1.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1357404405 14470 80.91.229.3 (5 Jan 2013 16:46:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2013 16:46:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 17:47:02 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 1TrWtf-0000Wk-Lk for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2013 17:46:59 +0100 Original-Received: from localhost ([::1]:50494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrWtQ-0001SQ-A9 for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2013 11:46:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrWtN-0001SL-4R for emacs-devel@gnu.org; Sat, 05 Jan 2013 11:46:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TrWtL-00073j-MU for emacs-devel@gnu.org; Sat, 05 Jan 2013 11:46:41 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:45846) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TrWtL-00073f-Fa for emacs-devel@gnu.org; Sat, 05 Jan 2013 11:46:39 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TrWtS-0000NN-Df for emacs-devel@gnu.org; Sat, 05 Jan 2013 17:46:46 +0100 Original-Received: from pd9eb269b.dip.t-dialin.net ([217.235.38.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jan 2013 17:46:46 +0100 Original-Received: from Stromeko by pd9eb269b.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jan 2013 17:46:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb269b.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux) Cancel-Lock: sha1:QU7UgKjzFv5e2IcIebfgHfDKxTc= 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:156090 Archived-At: Ted Zlatanov writes: > SSL can easily be compromised and may not be available on all > platforms. I won't comment on that assertion, but in any case transport layer security solves only a tiny part of the problem. As far as the end user is concerned, what she really needs to know is that the files on disk have not been tampered with compared to what the maintainer intended to distribute. This is a general problem with Emacs, not just with ELPA and the solution IMHO doesn't lie with the development process either (it's good to have a verifyable development process, but that doesn't address the problem at hand). So there are at least three checks to make: check the metadata before the download, then the downloaded archive itself and then again that the stuff unpacked from that archive matches the distribution. Lastly, maybe a fourth check that after compiling the package no extra or missing files are recorded. This can be done via checksumming and comparison with a manifest, which in turn needs to be signed. Optimally the manifest would be signed by the maintainer(s) of the package upon release and then again by whoever runs the package archive upon publication, preferrably with some note that the maintainer credentials have been checked successfully and when. Also the metadata should be signed so that a rogue ELPA server or mirror can not distribute files to the end user easily. Since installing a package produces additional files, they should probably be listed in the manifest (without checksum) to ensure that no malicious files are planted upon installation. That moves all the authenticity issues to the signatures or rather the trust you have in the keys used to produce them. CPAN/PAUSE can be used as an example of how something like this works out in practise (Debian apt or openSUSE zypper are further examples, but they operate on a different scale). Emacs would need to be deployed so that it knows its own signing key as well as the (preferably separate) key for ELPA. I don't think that it should implicitly trust them, though, so the user should explicitly consent to trusting the key (either temporarily or permanently). Note that (D)VCS doesn't come into play at any level of this unless you intend to publish packages directly from the DVCS they are developed in. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables