github.com/fibonacci-chain/fbc@v0.0.0-20231124064014-c7636198c1e9/dev/wasm/escrow/Importing.md (about)

     1  # Importing
     2  
     3  In [Publishing](./Publishing.md), we discussed how you can publish your contract to the world.
     4  This looks at the flip-side, how can you use someone else's contract (which is the same
     5  question as how they will use your contract). Let's go through the various stages.
     6  
     7  ## Getting the Code
     8  
     9  Before using remote code, you most certainly want to verify it is honest.
    10  There are two ways to get the code of another contract, either by cloning the git repo
    11  or by downloading the cargo crate. You should be familiar with using git already.
    12  However, the rust publishing system doesn't rely on git tags (they are optional),
    13  so to make sure you are looking at the proper code, I would suggest getting the
    14  actual code of the tagged crate.
    15  
    16  ```sh
    17  cargo install cargo-download
    18  cargo download cw-escrow==0.1.0 > crate.tar.gz
    19  tar xzvf crate.tar.gz
    20  cd cw-escrow-0.1.0
    21  ```
    22  
    23  (alternate, simpler approach, but seems to be broken):
    24  
    25  ```sh
    26  cargo install cargo-clone
    27  cargo clone cw-escrow --vers 0.1.0
    28  ```
    29  
    30  ## Verifying Artifacts
    31  
    32  The simplest audit of the repo is to simply check that the artifacts in the repo
    33  are correct. You can use the same commands you do when developing, with the one
    34  exception that the `.cargo/config` file is not present on downloaded crates,
    35  so you will have to run the full commands.
    36  
    37  First, make a git commit here, so we can quickly see any diffs:
    38  
    39  ```sh
    40  git init .
    41  echo target > .gitignore
    42  git add .
    43  git commit -m 'From crates.io'
    44  ```
    45  
    46  To validate the tests:
    47  
    48  ```sh
    49  cargo build --release --target wasm32-unknown-unknown
    50  cargo test
    51  ```
    52  
    53  To generate the schema:
    54  
    55  ```sh
    56  cargo run --example schema
    57  ```
    58  
    59  And to generate the `contract.wasm` and `hash.txt`:
    60  
    61  ```sh
    62  docker run --rm -v "$(pwd)":/code \
    63    --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
    64    --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
    65    cosmwasm/rust-optimizer:0.9.0
    66  ```
    67  
    68  Make sure the values you generate match what was uploaded with a simple `git diff`.
    69  If there is any discrepancy, please raise an issue on the repo, and please add an issue
    70  to the cawesome-wasm list if the package is listed there (it should be validated before
    71  adding, but just in case).
    72  
    73  In the future, we will produce a script to do this automatic verification steps that can
    74  be run by many individuals to quickly catch any fake uploaded wasm hashes in a
    75  decentralized manner.
    76  
    77  ## Reviewing
    78  
    79  Once you have done the quick programatic checks, it is good to give at least a quick
    80  look through the code. A glance at `examples/schema.rs` to make sure it is outputing
    81  all relevant structs from `contract.rs`, and also ensure `src/lib.rs` is just the
    82  default wrapper (nothing funny going on there). After this point, we can dive into
    83  the contract code itself. Check the flows for the handle methods, any invariants and
    84  permission checks that should be there, and a reasonable data storage format.
    85  
    86  You can dig into the contract as far as you want, but it is important to make sure there
    87  are no obvious backdoors at least.
    88  
    89  ## Decentralized Verification
    90  
    91  It's not very practical to do a deep code review on every dependency you want to use,
    92  which is a big reason for the popularity of code audits in the blockchain world. We trust
    93  some experts review in lieu of doing the work ourselves. But wouldn't it be nice to do this
    94  in a decentralized manner and peer-review each other's contracts? Bringing in deeper domain
    95  knowledge and saving fees.
    96  
    97  Luckily, there is an amazing project called [crev](https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/README.md)
    98  that provides `A cryptographically verifiable code review system for the cargo (Rust) package manager`.
    99  
   100  I highly recommend that CosmWasm contract developers get set up with this. At minimum, we
   101  can all add a review on a package that programmatically checked out that the json schemas
   102  and wasm bytecode do match the code, and publish our claim, so we don't all rely on some
   103  central server to say it validated this. As we go on, we can add deeper reviews on standard
   104  packages.
   105  
   106  If you want to use `cargo-crev`, please follow their
   107  [getting started guide](https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/src/doc/getting_started.md)
   108  and once you have made your own *proof repository* with at least one *trust proof*,
   109  please make a PR to the [`cawesome-wasm`]() repo with a link to your repo and
   110  some public name or pseudonym that people know you by. This allows people who trust you
   111  to also reuse your proofs.
   112  
   113  There is a [standard list of proof repos](https://github.com/crev-dev/cargo-crev/wiki/List-of-Proof-Repositories)
   114  with some strong rust developers in there. This may cover dependencies like `serde` and `snafu`
   115  but will not hit any CosmWasm-related modules, so we look to bootstrap a very focused
   116  review community.