Re: ELPA security

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 07 Jan 2013 22:07:05 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

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

SM> The tarball contains nothing else than the source, and it can only be
SM> downloaded as a whole, so there's no point signing each file in
SM> a tarball individually.

OK.  So there's one signature, either for a standalone .el file, or for
the whole tarball.  It makes sense, then, to host it in
`archive-contents'.

>> I'd like to settle the signing keys (will it be the authors or a group
>> of GNU ELPA maintainers?);

SM> The signing will not guarantee any kind of code quality, it will only
SM> guarantee "this comes from the real GNU ELPA".  So the signing key will
SM> be a "GNU ELPA" key.

OK, great.

>> `archive-contents' (will its format change?);

SM> Yes and no: each entry in it will have one more optional field
SM> containing the signature.  AFAIK it should be backward compatible, so
SM> it's a change, but will still work with older package.el.

OK, so the package vector will have a new element.  Releasing a package
will require releasing a new `archive-contents' with an updated
signature for that package and re-signing it with the "GNU ELPA"
maintainer key.

Last question: do you want to provide for files that may show up during
compilation?  They could be ignored (current behavior), or warned about,
or could cause installation to be rejected.

Ted