Conversation
This should maybe be a warning instead of an error, but I'll need to experiment with this more.
Since releases of `cargo-contract` are now bundled with a `wasm-opt` library we can assume that equal versions of `cargo-contract` contain equal versions of `wasm-opt`.
git update-ref -d MERGE_HEAD
ascjones
left a comment
ascjones
left a comment
There was a problem hiding this comment.
One more thing: a lot of trust will be put into this command, therefore we should have integration tests here for both the positive and negative results of this command.
I doubt we will be able to simulate different OS environments, but minor changes in the code should work. |
| tracing::debug!("Building contract in {}", project_dir.to_string_lossy()); | ||
| cargo_contract(&project_dir) | ||
| .arg("build") | ||
| .arg("--release") |
There was a problem hiding this comment.
Oddly, without the flag, the cargo contract build produces different wasm binaries even though the crate name and code are identical but places in differnt temp dirs.
ascjones
left a comment
ascjones
left a comment
There was a problem hiding this comment.
LGTM.
Might be good as a next step to be able to verify from a contract account id that it is an instance of the verified contract. Should be straightforward just by looking up the code hash and then comparing that.
3 participants
Supersedes #696
Adds a
cargo contract verify <path to reference contract bundle>command which allows to verify if the given contract code matches the reference bundle.In addition to the previous PR, I have added the support to verify "verifiable" contract. If the contract bundle specify
imagein metadata, then we build the target contract code in the container of the specified image and then verify.This PR also locks the version of
wasm-optcrate which often is the cause of binary mismatch.