Have a checksum performed on pre-built binaries being downloaded

[IceTDrinker]

First of all thanks a lot for the work on this tool, much appreciated.

💡 Feature description

I was going to bump wasm-opt in wasm-pack due to the much better runtimes of newer versions and I saw it has been done already (thanks for that !).

I was wondering while planning the above if the prebuilt binaries should be submitted to a sha256 checksum to make sure there is nothing fishy going on.

Essentially the sha256 digests from github would be added as hardcoded strings in the code and using a sha256 crate, or a shasum executable, the integrity of the downloaded file could be checked.

I've taken a habit to run sha256 on downloaded artifacts in projects I work on and I didn't think about how wasm-pack was managing binaries until I had to dig into a fairly slow wasm-opt call.

Cheers

[IceTDrinker]

Open to contributing if there are preferred ways of doing this

Also the question of some automation to update sha256 is in play here to avoid making updating binaries something people don't do anymore if the manual sha256 addition is a problem

[guybedford]

This is definitely a worthwhile thing to do - a PR to add this feature would be welcome. The publish workflow-related aspect is worth putting some thought to. It can be as simple as a statically included local file that provides the version and sha data during built time, where that file can be updated via a script. In terms of version management complexities etc, maybe worth keeping it simple - the file already has a set of hard-coded versions, a integrity script reads that file, and updates the hashes to be valid?

[IceTDrinker]

not sure I followed all your thoughts

here is arough idea of how I'd go about it, probably a set of constants in a rust file that can be easily autogenerated and the relevant locations would make reference to some hardcoded constants

rough sketch

sha256_refs.rs

//! Autogenerated do not modify by hand
//! call "magic command" to regenerate

WASM_OPT_V129_X64_LINUX_SHA256: &str = "...";
...

sha256_helper.rs

use sha256_refs::*;

pub fn get_sha256(tool, version, os, platform) -> &'static str {
// code that never changes and returns the right str
}

code needing the ref str could call the function

[guybedford]

It's a wide space, but to flesh out the suggestion -

version-manifest.toml

[wasm-opt]
version = "129"
release.linux-foo = "release url with {version} marker"
release.windows-bar = "release url with {version} marker"
integrity.linux-foo = "<sha>"

[another-tool]
// ...

update-shas.rs

// ... script that reads version-manifest.toml and updates the sha entries, then re-saves it

Then in the wasm-pack code it would share the serde types to read the manifest and use it as the source of truth for URLs, versions and shas (effectively refactoring a bunch of resolve & lookup code). The benefit being that the integrity updater and wasm-pack internals use the same source of truth then internally.

Bumping a version then becomes changing the version in the manifest, and running the script against the manifest. This way the process of informing versions is unified on updates to the manifest version bump with a following integrity bump.

[IceTDrinker]

Manifest would be included in wasm-pack with an include_str! Macro ?

I thought about it and it might have been heavy, but if a toml parser is already in the deps that makes sense