From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Nathan Newsgroups: gmane.emacs.devel Subject: Re: ELPA security Date: Sun, 6 Jan 2013 21:32:11 -0800 Message-ID: References: <8738zf70ep.fsf@riseup.net> <871uejlbm1.fsf@lifelogs.com> <87k3rrr31g.fsf@Rainer.invalid> <874nium8h0.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=90e6ba211fbfb15a6504d2ac2645 X-Trace: ger.gmane.org 1357536739 6925 80.91.229.3 (7 Jan 2013 05:32:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Jan 2013 05:32:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 07 06:32:36 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 1Ts5K7-000660-Ic for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2013 06:32:35 +0100 Original-Received: from localhost ([::1]:40762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ts5Jr-0004AR-U0 for ged-emacs-devel@m.gmane.org; Mon, 07 Jan 2013 00:32:19 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50507) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ts5Jo-00049L-AO for emacs-devel@gnu.org; Mon, 07 Jan 2013 00:32:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ts5Jm-0002hw-Fy for emacs-devel@gnu.org; Mon, 07 Jan 2013 00:32:15 -0500 Original-Received: from mail-vc0-f175.google.com ([209.85.220.175]:51287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ts5Jm-0002hl-9u for emacs-devel@gnu.org; Mon, 07 Jan 2013 00:32:14 -0500 Original-Received: by mail-vc0-f175.google.com with SMTP id fy7so18980839vcb.34 for ; Sun, 06 Jan 2013 21:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zA63TP28Fodfyt98VsnqC7HR5Du9DFo2Va20V9fUWV4=; b=bxf2KUhoESUWMtK0FYieErZXfRNHeupNyQvOmufy0EWYTdjd320FVkqQeAvPCkKX9B FHdrxnT4ZEgczAEstkPGmgo9tj7ZDcN7G0ZKR0v9CSxVknQpUBep+OMu0YJu6Jtr5BZH s+fLTCd88Sw87iEjQ4qSIHBq70Dv03/VJz0apJ8/4BkBPqKrZ3Hu5gFgQxDLPmcUoRsI YhaHci3gfFz3BuV/BZCzkWMr6ZRqvRoLZM6jRfCm4pfqv22AyAs3jXwJ+acOI8IMItAu e21wtmljGQ5bJXvM2fZjPR7BCRwPkkw6qYzsWTMIiqMkBmh3j8wdalMj9Bp7L+WTFOaH 9NyQ== Original-Received: by 10.221.2.69 with SMTP id nt5mr81942822vcb.68.1357536732207; Sun, 06 Jan 2013 21:32:12 -0800 (PST) Original-Received: by 10.220.141.212 with HTTP; Sun, 6 Jan 2013 21:32:11 -0800 (PST) In-Reply-To: <874nium8h0.fsf@lifelogs.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.175 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:156104 Archived-At: --90e6ba211fbfb15a6504d2ac2645 Content-Type: text/plain; charset=ISO-8859-1 [snip] > I think it's easier to simply require that every file have its own .sig > and avoid the verification chain from manifest to archive contents. > Then we rely on GPG to handle signing and verification for us, no matter > who actually generates the .sig files (as long as their signing key is > trusted by us). I don't think checksums have any advantage there, but > maybe you see some? > > I think the GNU ELPA maintainers should sign everything, but that's > debatable and not essential to the proposal. > > AG> Since installing a package produces additional files, they should > AG> probably be listed in the manifest (without checksum) to ensure that > AG> no malicious files are planted upon installation. > > I don't know if that's needed, but have no problem with it as a feature. > > AG> That moves all the authenticity issues to the signatures or rather the > AG> trust you have in the keys used to produce them. > > Yes, that's exactly what I'm trying to accomplish, instead of relying on > SSL/TLS or other transport-level solutions. > > > Hullo, It appears that the simplest so far is to use per-package signature files for GPG verification, keeping the gpg pubkeys downloaded with gnu emacs or separately downloaded. I am perhaps unlearned, but directly using version control seems like it would add some complexity. The idea of having a data file and a signature file seems to be much more straightfoward. Perhaps this could be most easily accomplished by some sort of post-download hook ("check package file to verify signature authenticity"), along with a list of known GPG keys stored in some ~/.emacs.d/package-keys folder. One downside to this proposal seems to be that it would link gnu emacs with gnu privacy guard fairly tightly as a dependency. I see several aspects here (perhaps I am missing something) - - GPG could be compromised on the user's computer(this probably indicates all is lost) - GPG must be distributed with GNU Emacs, or else partially reimplemented in elisp. Some operating systems are not shipped with gpg. - The verification and import interfaces must be very simple and obvious to users ignorant in cryptography. It is no good if many people just disable it because it is too problematic to use. I have the idea that this idea is very simple to prototype if gpg can be shelled out to. A cursory reading of package.el suggests to me that package-download-transaction could have the verification added. I could help out here if it is acceptable for a novice to help. Kind regards, Paul --90e6ba211fbfb15a6504d2ac2645 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
[snip]
=A0
I think it's easier to simply require that every file have its own .sig=
and avoid the verification chain from manifest to archive contents.
Then we rely on GPG to handle signing and verification for us, no matter who actually generates the .sig files (as long as their signing key is
trusted by us). =A0I don't think checksums have any advantage there, bu= t
maybe you see some?

I think the GNU ELPA maintainers should sign everything, but that's
debatable and not essential to the proposal.

AG> Since installing a package produces additional files, they should AG> probably be listed in the manifest (without checksum) to ensure that=
AG> no malicious files are planted upon installation.

I don't know if that's needed, but have no problem with it as a fea= ture.

AG> That moves all the authenticity issues to the signatures or rather t= he
AG> trust you have in the keys used to produce them.

Yes, that's exactly what I'm trying to accomplish, instead of relyi= ng on
SSL/TLS or other transport-level solutions.



Hullo,

It ap= pears that the simplest so far is to=20 use per-package signature files for GPG verification, keeping the gpg=20 pubkeys downloaded with gnu emacs or separately downloaded.=A0 I am=20 perhaps unlearned, but directly using version control seems like it=20 would add some complexity. The idea of having a data file and a=20 signature file seems to be much more straightfoward.

Perh= aps this could be most easily accomplished by some sort of post-download=20 hook ("check package file to verify signature authenticity"), alo= ng with a list of known GPG keys stored in some ~/.emacs.d/package-keys folder.
One downside to this proposal seems to be that it would link gnu emacs with gnu privacy guard fairly tightly as a dependency. I see several aspects here (perhaps I am missing something) -

- GPG could be = compromised on the user's computer(this probably indicates all is lost)=
- GPG must be distributed with GNU Emacs, or else partially reimplemented in elisp. Some operating systems are not shipped with gpg.
- The verification and import interfaces must be very simple and obvious=20 to users ignorant in cryptography. It is no good if many people just=20 disable it because it is too problematic to use.


I have the idea that this idea is very simple to prototype if gpg can be=20 shelled out to. A cursory reading of package.el suggests to me that=20 package-download-transaction could have the verification added.=A0 I could help out here if it is acceptable for a novice to help.

= Kind regards,
Paul


=A0

--90e6ba211fbfb15a6504d2ac2645--