-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to work with source and builder? #77
Comments
These definitely need to evolve somehow, along with tools to consume them. Here are my current ideas, for Rust code. For other languages, we would need other conventions. And we should provide a verifier program that can process a number of conventions, leaving the format as an agreement between the code uploader and the verifying agent, where the blockchain only enforces some sanity checks. For Rust, I would propose:
In the end, the idea was to provide some metadata about a user-provided claim of the source code behind the wasm and enough info that someone could verify it. Of course, this only works if both sides speak the same conventions, and know the docker image. My idea was to script a workflow that took Either everyone can do this themselves, or we can have some sort of a way for people to publish claims that yes, they validated this is the source code, and if sufficient trusted people say so, we can just go to browse the source. Ideally with some web UI for this. As to making such claims of the validity of the hash, my idea was to reuse the The above is my current thoughts, this should definitely be refined and documented. Then we can work on some tooling for it |
As to what is enforced on the server...
I requested a builder tag check as valid docker image, but got this (which was good enough for now, so I merged it). For a correct solution, we would investigate and test out a better docker regexp. I am not sure what the proper regexp would be, but found this suggestion.
Yes, it should be an absolute URL (docs need improvement), and we could enforce the protocol to be |
This can be generalized to optionally compressed tar archives, which you can download and extract from crates.io with
Or for GitHub (no subfolder links supported, only full repo)
|
What is left is documenting this better somewhere. Code is cleaner |
I sucessfully verified a cw-nameservice .wasm file against its source in a semi-automated way with #!/bin/bash
set -o errexit -o nounset -o pipefail
command -v shellcheck > /dev/null && shellcheck "$0"
SOURCE_URL="https://crates.io/api/v1/crates/cw-nameservice/0.1.0/download"
BUILDER_IMAGE="confio/cosmwasm-opt:0.6.2"
TMP_DIR=$(mktemp -d "${TMPDIR:-/tmp}/cosmwasm_verify.XXXXXXXXX")
(
echo "Navigating into working directory $TMP_DIR ..."
cd "$TMP_DIR"
echo "Downloading and extracting $SOURCE_URL ..."
wget -O - "$SOURCE_URL" | tar -x --strip-components 1
echo "Files in working directory:"
ls .
CACHE_KEY="cosmwasm_verify_cache_$(echo "$SOURCE_URL" | xxd -p -c 999999)"
docker run --rm \
-v "$(pwd):/code" \
--mount type=volume,source="$CACHE_KEY",target=/code/target \
--mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
"$BUILDER_IMAGE"
cat hash.txt
) With the server-side changes we have right now, this works for any
|
This is done and tested. A builder agnostic verifier is here: https://github.com/confio/cosmwasm-verify, including a bunch of documentation about usage and conventions. |
Very cool. |
* Update SDK version * Remove x/crypto replace * remove colors * Add all allInvariants
* fix: use ctx cache in msg server integration test Signed-off-by: 170210 <[email protected]> * chore: add this PR to CHANGELOG Signed-off-by: 170210 <[email protected]> --------- Signed-off-by: 170210 <[email protected]>
A code's
source
andbuilder
are "a valid URI reference to the contract's source code" and "a docker tag", but what does that mean semantically? What's the purpose? How are they used?Some issues I see here are:
https://github.com/confio/cosmwasm-examples/tree/f87f7a3d6d7ec1abd77a4b4bc2388799a4fe4c26/erc20
is nice for human consumption, but does not allow for reproducible builds (assuming we're not planning to restrict to one code hoster). You could expect an archive (.tar/.zip) URL. But is that the way forward?So right now the fields don't seem to be sufficiently compete for machine consumption. Are they just hints to the user? If so, why is there a builder format check?
Side note:
source
is documented to be an URI but checked to be an absolute URL.The text was updated successfully, but these errors were encountered: