On Wed, 19 Jun 2013 01:02:16 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> etc/elpa/ARCHIVE-NAME can contain the actual armored GPG signature but
TZ> it can also have more metadata about the archive.  So the format could
TZ> be:

TZ> url=ARCHIVE-URL
TZ> other-metadata=whatever
TZ> then-a-new-line=ends metadata

TZ> SIGNATURE

TZ> and if SIGNATURE is missing, the archive is not signed.

TZ> This would augment `package-archives' on startup and on demand.

Any opinions here?

For now I'm using the old format.  Archives are signed by default as
requested.  I've rebased the patch against the changes to package.el.

If we push this change, it will break all users against all ELPA
archives until all their files are signed (they will have to answer 'y'
every time files are retrieved).  I think that's pretty radical.  Maybe
we should coordinate the change with all the repo maintainers?  Or come
back to my original setup, where archives are unsigned by default?

Finally, for easier testing I think we should put a fake archive with 1
package in test/elpa/packages.  If you agree I'll push that as a
separate commit, including a small self-contained test.  I didn't do it
because Stefan mentioned Daniel Hackney's changes included some testing
code and I didn't want to confuse matters.

TZ> Using EPG functions, however, I could not figure out how to verify with
TZ> an external public GPG key.  I don't see that option with any of the
TZ> context functions.  Perhaps someone knows?  Without that option, the
TZ> user has to explicitly load the maintainer's public GPG key, which is
TZ> very impractical around package.el.

I need to know the above to make the patch usable, so I won't commit for
now.

Also the signature has to be named .gpgsig because the extension .gpg
(the default) makes EPA/EPG attempt to decrypt it.

Ted