svm-rs icon indicating copy to clipboard operation
svm-rs copied to clipboard

solidity binaries always redownloaded on nixos

Open d-xo opened this issue 2 years ago • 4 comments

On nixos solidity binaries are always downloaded on every invocation of a forge command. I'm guessing this is due to some hash check failure as a result of the patching performed since: https://github.com/alloy-rs/svm-rs/pull/48.

I'm wondering what the best way to fix this is?

d-xo avatar Aug 03 '23 10:08 d-xo

does this change the binary:

https://github.com/alloy-rs/svm-rs/pull/48/files#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R82-R84

? if so then this would explain a hash mismatch

mattsse avatar Aug 03 '23 18:08 mattsse

yes that modifies the binary.

We could perhaps precompute the expected hashes on nixos and ship them as part of svm-rs? Or instead of patching the binaries locally, we could detect that we're running on nixos and pull from some trusted nix respository of solc binaries (e.g. https://github.com/dapphub/dapptools/blob/master/nix/solc-versions.nix, or https://github.com/hellwolf/solc.nix), in this case we would skip hash checks in svm and delegate integrity checking and so on to nix.

Happy to make a pr here, but would appreciate some guidance on what your prefered solution is.

d-xo avatar Aug 04 '23 10:08 d-xo

I like that.

one concern I have re additional solc bins, is that this makes adding new binaries more complex, but https://github.com/hellwolf/solc.nix looks well maintained and we could just use this for nix, so pulling from https://github.com/hellwolf/solc.nix would be easier to impl and the update overhead is still manageable.

but I'm fine with either solution.

mattsse avatar Aug 04 '23 11:08 mattsse

Using an external nix repo is probably the easiest to implement, but I'm a bit worried about supply chain risk and introducing additional trusted parties between the solidity team and the end user.

d-xo avatar Aug 04 '23 15:08 d-xo