Re: Package signing infrastructure suggestion (was Re: ELPA security)

[Ted Zlatanov]

On Mon, 31 Dec 2012 13:39:40 +0000 Nic Ferrier <address@hidden> wrote: 

NF> Ted Zlatanov <address@hidden> writes:
>> 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.

NF> ...

>> 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.

NF> It sounds like you are mixing up a lot of different things. 

NF> A package is an artifact from a build system and that separation between
NF> packages and repositories is a good thing.

In my proposal, the repository is not the classical source repository
that produces packages but a storage space for the ELPA packages, which
is how it's used by the GNU ELPA (a branch in the Emacs Bazaar repo).

I think for the ELPA it makes sense to strenghen that integration in
order to achieve package verification and other useful features, like
retrieving a specific verision of the ELPA repository or mirroring an
ELPA repository easily.

NF> A better solution is to have a standard location for signed packages,
NF> perhaps a derivable HTTP or file URL.

We can sign the key package with a key that's stored in Emacs itself.  I
was hoping not to bolt the security on top of the current HTTP mechanism
but to integrate it with the DVCS better, but if you and Tom and others
think it's better to piggyback on top of HTTP, I'll go along.

NF> A single package could be used to collect everyone's keys.

NF> When a new maintainer is added the key package would have to be
NF> updated.

NF> The key package could be constructed automatically from gpg key stores
NF> or individual uploads of keys. Something that assures we know who
NF> someone is.

NF> The key package should have a unique name derived from the repository so
NF> other repositories can support the same system if they wish to.

NF> It's quite important, I think, that the maintenance of the key package
NF> is separate from the signed packages themselves.

I understand your proposal and think it makes a lot of sense.  But how
is it better than signed commits with Bazaar or signed tags with Git?

With signed commits/tags, only one public key is needed (the repository
maintainer) and it's easy to say "right here, everything in this
repository is approved."  There's also no need to revoke packages in
this scheme, because you'd commit a revert of the earlier bad code and
sign that new commit.  And finally, there is no "key package" or much
else special... you just use the built-in DVCS facilities.

Ted