Create mechanism for committing hashes/checksums of published binaries to repos, and verifying them on install

[apendleton]

node-pre-gyp currently has no mechanism for detecting a situation in which a built binary has been tampered with on s3 since its initial publication. We should have a way, after publishing a binary or set of binaries, to commit a hash (potentially signed, but might not be necessary) of the published binary to source control, publish it to npm, etc. This hash can be checked at node-pre-gyp install time, and can fail if a file on s3 has been tampered with.

For repositories that build and publish automatically on CI infrastructure in a single step as part of a release, we'll have to think about how these hashes would best make their way back into the repo. Maybe we can come up with best practices for producing them as build artifacts of some kind?

cc @mapbox/security @flippmoke

[daniel-j-h]

By now lots of sensitive packages are using node-pre-gyp to download pre-built binaries, e.g.

• bcrypt
• argon2 (ticket)

and without a mechanism to verify the binary's integrity and authenticity, overwriting the packages with a malicious binary can not be detected and will never be noticed by users installing these packages.

[NilSet]

A security researcher recently acquired a lapsed s3 bucket which was previously being used by a widely distributed NPM package to host pre-gyp binaries, and uploaded his own binaries which phoned home environment variables, so this is no longer a theoretical problem.

[calebbrown]

This exploit could have been avoided with this feature. GHSA-xv2f-5jw4-v95m