Package signing infrastructure suggestion (was Re: ELPA security)

[Nic Ferrier]

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.

...

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

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

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

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

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

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

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

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

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



Nic Ferrier
Elnode, Marmalade, TeamChat.net