bug#19479: Package manager vulnerable to replay attacks

[Stefan Monnier <monnier@iro.umontreal.ca>]

> While not perfect, with a secure hash function, collisions are hard
> enough to find that we for our purposes (like the rest of the world) can
> happily not worry about it.  In comparison, it is immeasurably easier to
> fake a version number than having to defeat a hash function.  I think
> this is a significant drawback of what you propose.

I'm not sure what you mean by it being easier: since the tarballs are
cryptographically signed, just like `archive-contents`, if
`archive-contents` points to `foo-42.1.tar` and that tarball has
a correct signature and its content says that it is indeed the package
`foo-42.1`, then I'm not sure which easy attack would be applicable.

AFAICT you'd have to find some old signed tarball which we accidentally
built with an incorrect content?  But presumably if we ever mess up
a tarball like that (which is indeed possible), we'd then want to be
careful not to "reuse" that version number, no?

> We would need to add in a number of assumptions (e.g. packages are
> individually signed,

Which they already are.

> we never accidentally sign an old package with a newer version number,
> etc.),

That's indeed the case as well.

> to gain more confidence in a simple version
> number check.

I think it's comparable: the main failings wold require some error on
our side in how we build and sign packages, and in most such cases
I think we'd end up with holes with either scheme.

> But we could of course also check that the version number is correct.
> That sounds like a useful sanity check to do.

Exactly.

> PS. Note that if we add a checksum, there will no longer be any need to
>     sign individual packages for future versions of Emacs.  We would
>     then only need to sign the metadata.

I think we'd want to keep the signatures anyway, e.g. they can still be
checked manually for old tarballs which aren't listed in
`archive-contents` any more.  And more generally they allow
authenticating the origin of a package without having to look it up in
`archive-contents`.


        Stefan