Allow pinning the content of remote sources with hashes

[michaelpj]

This protects us against the use of mutable URL references, and also makes things more Nix friendly.

We might want to make it possible to require this.

[andreabedini]

💯

Questions/thoughts:

• What format for hashes? sha256 = ... ? Should we use the SRI format like nix has started doing? Would that be more future proof?
• What is the hash of? The fetched tarball? (o repo à la nix? is there even a standard way?).

[michaelpj]

What format for hashes?

I think SHA256 is generally good enough, and also we don't want to make these too difficult to produce, since we'll want add-from-github to populate it.

What is the hash of? The fetched tarball? (o repo à la nix? is there even a standard way?).

I think "whatever gets fetched from the URL" seems reasonable?

[michaelpj]

Putting in the hashes for old things will be annoying. We could have a foliage normalize command that puts them in for things that don't have them, though. Could be an extension of #55 but probably not called "format" (hence "normalize").

[michaelpj]

Another reason to do this: it gives us a bit more security against supply-chain attacks. At the moment we use github URLs a lot. These have git shas in them... but these days it's possible to manufacture collisions in git's hash algorithm.

A concrete example: if we move a repository from input-output-hk/X to intersect/X, then the original links will work as redirects. That is, unless someone makes a new repository input-output-hk/X, at which point the links will start to be relative to that repository. The attacker still needs to make commits with the same hashes as the ones in the URL, but you can do that by manufacturing a collision, allowing you to serve malicious package content.

SHA-256 is still collision-resistant, so if we had hashes in the meta.toml files we would at least notice this attack, so it would fail and just be annoying.