Force a move from sha1 to sha256 or sha512

[grahamc]

In 2017, #39 was opened due to a recent sha1 security scare. Well, a new one has come up and it is even cheaper to do (less than $50k). If npm isn't providing better than sha1, I think we should fetch the file, validate the sha1 matches, and then calculate a sha256.

What do you think about that? Right now, node2nix-built packages represent the vast majority of sha1 references in Nixpkgs, which we're trying to get rid of: https://github.com/NixOS/nixpkgs/issues/77238

[svanderburg]

@grahamc I do agree with you that we should get rid of weak hashes and make things (preferably) secure by default.

However, forcing all hashes to be stronger than SHA1, requires me to take responsibility to implement functionality to recompute SHA512 hashes, in case none was provided by NPM. Currently, node2nix simply adopts whatever property the NPM registry provides, so it tries to be as good as NPM, but not better.

I'm not sure how often we still encounter packages with SHA1 hashes. Adding, for example, libraries that can compute SHA512 makes the implementation of node2nix more difficult.

[svanderburg]

@grahamc There is another implication that I just realized why recomputing hashes is a bad idea. Right now, in order to generate packages we only have to fetch metadata from NPM registry (this metadata also contains the SHA1 or SHA512 hashes of the package). This process is extremely fast.

If we need to recompute the hashes, because some package does not provide a SHA512 hash, then we need to download the full package to recompute the hash.

As you may probably know, some NPM project have thousands of dependencies making the process extremely costly and time consuming.

[svanderburg]

@grahamc This is probably also an implication for other generators for other language specific package managers. Despite the fact that moving to stronger hashing methods is a good thing, it comes at a price.