bug#19479: Package manager vulnerable

[Kelly Dean]

Ivan Shmakov requested that I send this message to the bug list.

For details, see my message with subject ⌜Emacs package manager vulnerable to 
replay attacks⌝ to emacs-devel on 30 Dec 2014:
https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg02319.html

Executive summary to fix the vulnerabilities:

0. Include a hash and length of each package's content in the package's record 
in archive-contents, rather than only including the package name and version 
number in that file as Emacs currently does. Barf if a package hash doesn't 
verify, regardless of whether any signatures verify.
(Length technically not necessary, but still generally useful, e.g. if there's 
a length mismatch then you know there's a content mismatch and you don't have 
to bother checking the hash.)

Stop distributing elpa-key signatures of packages, since they're superfluous if 
you have package hashes in archive-contents and have elpa-key signatures of 
archive-contents, and you already have the latter.

1. Include a timestamp of archive-contents in that file itself (so that the 
signature in archive-contents.sig depends on the timestamp, so that the 
timestamp can't be forged), and have Emacs ignore any new archive-contents 
that's older than the latest valid one that Emacs has already seen or is older 
than some specified limit. One thing I forgot to mention in my original 
message: have Emacs signal a warning if it ever sees an archive-contents dated 
in the future, which indicates misconfiguration of the client or server (or of 
course, some kind of mischief).

Optional alternative timestamp handling, as Ivan pointed out that Debian does 
(at least sometimes): Instead of expiring archive-contents after some limit 
configured in Emacs, put an explicit expiration date in it. Personally, I don't 
like server-supplied expiration dates, kind of for a similar reason that RMS 
doesn't like server-supplied Javascript, or maybe just because I have too many 
irritating memories of expired SSL certs.

Ivan suggested maybe filing those as separate bug reports, but it's pointless 
to fix either of them unless both are fixed, so it makes more sense to include 
them together.

One more feature: include in each version of archive-contents a hash (and 
length) of the previous version of that file. This isn't necessary for 
preventing any of the vulnerabilities above, but it's easy insurance that 
slightly mitigates the disaster if the metadata signing key is compromised. 
It's pointless unless both the above problems are fixed, so it makes sense to 
put it here.

BTW, check whether Emacs is vulnerable to endless-data attack. (I haven't.) If 
it is, then the length field mentioned above (which is a good idea in any case) 
will assist in early detection of this attack. This belongs here because... 
well no it doesn't, but I don't want to file a separate bug report for it 
because the report would be bogus if it turns out Emacs isn't vulnerable, and 
I've already filled my bogusness quota for the week.