bug#17625: 24.4.50; All installed packages marked "unsigned", no archive listed

[Ted Zlatanov]

On Thu, 26 Jun 2014 15:51:25 -0400 Stefan Monnier <monnier@iro.umontreal.ca> 
wrote: 

SM> Whereas the feature you're discussing seems to be to indicate which
SM> candidates for installation have a signature available for checking
SM> (this is not implemented, AFAICT).
>> Is there a plan to implement the latter feature and can I help? I recall
>> some discussions months ago but no definite plan.

SM> I see 3 behaviors for it:
SM> - Mention at package-installation time that there's no signature to check,
SM>   maybe with a prompt to confirm the user really wants to go ahead.
SM>   This is more or less the route taken by APT, AFAIK (at least, seen
SM>   from the user's point of view).

SM> The first behavior [] should be very easy to implement.

Great, this is an improvement on the current situation and will
encourage package maintainers to sign their packages. But it must be one
prompt per queue, not per package, so it's not too annoying. Also
consider users without GnuPG, what should they see?

SM> - Keep track of which archives have signatures and which don't (e.g. by
SM>   assuming that if `archive-contents' has a sig, then the packages also
SM>   have sigs).  Then somehow display this info in the package list.

I think that's a safe assumption and can be just an extra 1-char column
after the archive name for the package. It's the logical UI companion to
the install-time prompt so the user knows to expect the prompt later.

SM> - Check each and every package to see if it has a sig.  This implies
SM>   a lot more network communication, AFAICT, so I think it's not
SM>   a good idea.

Agreed.  In addition, just because a package has a valid signature when
you list it doesn't mean it will be present or valid when you install it.

Do you have a plan to start signing GNU ELPA packages so this can get
tested in a real network setup?  Just one is enough.  I didn't mean to
hijack this ticket; we can continue the discussion on emacs-devel or
in a new ticket.

Thanks
Ted