Lets avoid storing binaries to our repository

[nagisa]

The recent incident in the xz/lzma world came from the malicious code hidden away in a binary test artifact.

We also have some binary artifacts in our repository:

• [ ] *.wasm containing various test artifacts
  • These are usually executed in a well known test sandbox so they might be fine?
  • I would like to imagine changes to the runtime would be pretty obvious if they introduce a way to escape the sandbox... OTOH wasmtime does support wasi, and we may be just one mistake away from enabling that... So better off if we compiled these contracts from source. We have a whole crate dedicated to test contracts.
• [ ] runtime/near-wallet-contract/res/*.wasm containing a wallet contract that's pre-deployed to certain accounts
  • Seems pretty risky. High profile target. If one was successful in injecting something nasty in there, we'd likely be looking at ether being drained from people's retirement savings accounts...
• [ ] runtime/runtime-params-estimator/emu-cost/counter_plugin/qemu-x86_64 and libcounter.so
  • Yikes. I had originally removed these but had to put them back in in #10620. I think any potential benefits in reproducibility or convenience are very well not worth it here.
• [ ] runtime/runtime-params-estimator/estimator-warehouse/data_dump_*.bin
  • No idea what these are, but I doubt these need to be checked in;
• [ ] runtime/runtime-params-estimator/res/*.wasm
  • No reason we couldn't compile the contracts necessary for estimation from source...
• [ ] pytest/tests/loadtest/locust/res/*.wasm
  • Similarly no reason we couldn't compile the contracts here from source...

cc @Ekleog

[birchmd]

runtime/near-wallet-contract/res/*.wasm

In theory these can be removed because it should be possible to have every developer build them locally via the build script logic. Currently this requires docker, which I am not sure if it is considered a necessary part of developing for Near today. I am also not sure how that would interact with the current CI.

The reason I used Docker is because this is the recommended way of doing reproducible builds with near-sdk. If a fully reproducible build can be achieved with cargo along then that could simplify the build.

[nagisa]

The reason I used Docker is because this is the recommended way of doing reproducible builds with near-sdk. If a fully reproducible build can be achieved with cargo along then that could simplify the build.

Well, it definitely is an easy to understand (and difficult to get wrong) way of constructing an environment for reproducible builds, but it is indeed very possible to have reproducible Rust builds without containerization as evidenced by the likes of Debian very successfully doing so for large number of much larger rust projects.

Here's a relevant RFC that ought to make it a single cargo toggle away, but all the prerequisite functionality is already made available by the Rust compiler.