On Mon, 17 Jun 2013 03:20:41 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sun, 16 Jun 2013 19:12:02 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>>> * add `package-signed-archives', a list of logical archive names with
>>> default '("gnu").  Add `package-archive-signed-p' to check it.

SM> I'd opt for the opposite, i.e. list the archives that aren't signed.

SM> And maybe automatically eliminate an archive from that "not signed"
SM> list if we ever find a signature in it.

TZ> How about basing the decision on the existence of
TZ> etc/elpa/ARCHIVE-NAME.signed which can then tell us more about the way
TZ> the archive is signed without customizing ELisp code?  Like a Yum or APT
TZ> repository description you can drop in?  I could use it to automatically
TZ> augment `package-archives' if you think that's useful, so it becomes
TZ> very manageable for a whole site.

I haven't made this change.  I'll wait for some opinions.  I think the
".signed" extension is unnecessary.

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

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

SIGNATURE

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

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

>>> If you're OK with the code changes I'll get them working and start
>>> implementing `package--verify-signature'.

SM> Go ahead,

The attached patch implements `package--verify-signature' and
`package--create-detached-signature' using EPG functions, against the
currently-loaded GPG keys.  Otherwise it's the same as before.
`package--create-detached-signature' is pretty easy from the command
line as well (see http://gnupg.org/gph/en/manual/x135.html).

From the command line, exporting and importing public GPG keys is easy,
e.g. "gpg --armor --output /tmp/tzz.gpg --export tzz@lifelogs.com".  So
the workflow is not difficult.

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

Ted