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: ELPA security Date: Mon, 07 Jan 2013 10:01:48 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87zk0ljaub.fsf@lifelogs.com> References: <8738zf70ep.fsf@riseup.net> <871uejlbm1.fsf@lifelogs.com> <87k3rrr31g.fsf@Rainer.invalid> <874nium8h0.fsf@lifelogs.com> 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 1357570929 8577 80.91.229.3 (7 Jan 2013 15:02:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Jan 2013 15:02:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 07 16:02:27 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 1TsEDa-0006CM-DX for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2013 16:02:26 +0100 Original-Received: from localhost ([::1]:55771 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsEDK-0001Az-TD for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2013 10:02:10 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsEDD-0000qp-5F for emacs-devel@gnu.org; Mon, 07 Jan 2013 10:02:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsEDB-0003lZ-P2 for emacs-devel@gnu.org; Mon, 07 Jan 2013 10:02:03 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:51510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsEDB-0003lR-I2 for emacs-devel@gnu.org; Mon, 07 Jan 2013 10:02:01 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TsEDP-0005xV-Ml for emacs-devel@gnu.org; Mon, 07 Jan 2013 16:02: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 ; Mon, 07 Jan 2013 16:02: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 ; Mon, 07 Jan 2013 16:02:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 60 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:vSmb4+38syEhrhmWHJhl0VGxRMc= 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:156117 Archived-At: On Sun, 6 Jan 2013 21:32:11 -0800 Paul Nathan wrote: PN> It appears that the simplest so far is to use per-package signature files PN> for GPG verification, keeping the gpg pubkeys downloaded with gnu emacs or PN> separately downloaded. I am perhaps unlearned, but directly using version PN> control seems like it would add some complexity. The idea of having a data PN> file and a signature file seems to be much more straightfoward. Yes, I think that's the agreement. I'd rather keep a .sig for every file instead of signing the whole package, because then you can package the whole directory in one tarball or distribute it as source, but that's a technicality IMO. PN> Perhaps this could be most easily accomplished by some sort of PN> post-download hook ("check package file to verify signature authenticity"), PN> along with a list of known GPG keys stored in some ~/.emacs.d/package-keys PN> folder. Yup. But EasyPG and GPG manage keys already, so perhaps the storage should be through them, instead of external. PN> One downside to this proposal seems to be that it would link gnu emacs with PN> gnu privacy guard fairly tightly as a dependency. I see several aspects PN> here (perhaps I am missing something) - PN> - GPG could be compromised on the user's computer(this probably indicates PN> all is lost) PN> - GPG must be distributed with GNU Emacs, or else partially reimplemented PN> in elisp. Some operating systems are not shipped with gpg. PN> - The verification and import interfaces must be very simple and obvious to PN> users ignorant in cryptography. It is no good if many people just disable PN> it because it is too problematic to use. Yup. We discussed this and Stefan said that for now at least, we'll live with the GPG dependency. I think eventually we'll implement enough of the OpenPGP protocol to do signature verification in C. That would address these concerns which I had as well, but it should not block us now. PN> I have the idea that this idea is very simple to prototype if gpg can be PN> shelled out to. A cursory reading of package.el suggests to me that PN> package-download-transaction could have the verification added. I could PN> help out here if it is acceptable for a novice to help. I believe EasyPG (epg.el) already has the functions to do all the signature verification work securely (e.g. it does the data transfer to GPG and back as securely as possible). So the POC is definitely possible. I'd like to settle the signing keys (will it be the authors or a group of GNU ELPA maintainers?); `archive-contents' (will its format change?); and signature files (will we have one per file, one per package, etc.?) questions first. Also Tom Tromey and Paul Hagelberg and the other package.el authors have not commented on our latest discussions, and I think their voices are important as they have contributed so much of the package.el code and design. But if you want to start on a POC, please feel free. I really think it would be a good start and don't wish to discourage you. Ted