Re: ELPA security

[Ted Zlatanov]

On Wed, 26 Dec 2012 09:32:44 -0800 Paul Nathan <address@hidden> wrote: 

PN> - In general, GNU is trusted (after all, we download our emacs from the
PN> GNU). This would imply to me that the GNU can GPG sign packages with a
PN> private/public key (Perhaps the precursor to this is emacs having a gpg
PN> implementation included).

Hmm.  So maybe there can be signed checkpoint commits to a global
ChangeLog file that validate all the commits up to that commit?  Then
package.el would pull that commit from the ELPA DVCS repository and
ignore all later, unconfirmed commits?  That seems very workable for the
maintainers and for package.el:

1. add DVCS support to package.el, supporting Git and Bazaar, with the
notion of "pull packages from repo X at tag/commit Y" in addition to the
current "pull packages from URLs".  The VC package has to be involved
here, instead of writing custom code.

2. when the user requests it and we can support it, we verify that Y is
signed with the ELPA maintainer key.  This will be optional, but for the
GNU ELPA we'll check by default and warn if the verification fails.  The
VC package may be involved here or it could be done in package.el; the
underlying verification will be done by an external tool at first and
may be implemented internally in Emacs later.

3. we may need a way to revoke a signed commit.  Perhaps it can simply
be a revert of the previously committed "bad" code, followed by another
commit, instead of a full revocation process.

4. I don't think we should provide this mechanism without a DVCS that
supports signing a tag or a commit.  In other words, let's not try to
bolt it on top of the current HTTP ELPA structure.

PN> - Then perhaps other repositories, such as marmalade could also sign their
PN> packages, and users could choose to trust that signature or not.

PN> - Of course, this is analogous to the Debian/Launchpad/PPA approach, which
PN> has worked excellently for me and others. It may require quite a great deal
PN> of infrastructure work which I am entirely unfamiliar with.

I think the proposal above minimizes new infrastructure.  It moves the
verification and signing burden to the ELPA (e.g. the GNU ELPA)
maintainers, which I think is the right place.  The new DVCS repo
pointers in package.el can coexist with the current HTTP pointers for a
nice gradual transition.

If this sounds acceptable I will start on a POC.

Ted