Verifying a buildalpha

Check what the compiler canister built, from which files, and with which compiler.

moxzi verify reads a build record from the compiler canister and checks it. It needs no identity and costs nothing.

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai --job 1

job             1
entry           /src/hello.mo
files           1
sourcesDigest   bd1434f9c83abd6f0c21843a1a3ebba433a63bff2026fe0a5efd1bf8573a3341
optionsDigest   db700b01e8f9e20ce5ad629775f7529a924826df19c8f95c86cdf7b02d9ef649
compilerVersion 1.14.1
cacheVersion    (unset)
artifact        da33c8358aa785232eeb93c51b695ee24599839cbaf80ef80940ff9b4abee9a1  (61650 B, unlinked)
kernels         (none recorded)

ok    sourcesDigest recomputed from 1 files and matches
ok    canister module hash (from the IC) 9294817c6e9069cbd0e712d0e9dde0ec1b6893d0e7b42d798fa3dd4c8cd772cb

*** 1 check(s) passed ***

Omit --job to check the most recent build, or run with --list instead of --job to see recent builds and their ids.

Check your source#

--entry compares each recorded file hash with the files on your machine:

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai \
  --job 42 --entry src/main.mo

A file that differs is reported by name.

Check a wasm#

--artifact compares a wasm file's hash with the recorded artifact hash:

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai \
  --job 42 --artifact main-unlinked.wasm

The recorded hash is for the module before linking. Linking is deterministic, so the same unlinked module always produces the same deployable module.

Check the compiler#

--expect-module checks that the canister is running a particular wasm. Pass the compiler you have locally:

moxzi verify --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai --job 1 \
  --expect-module ~/.local/lib/moxzi/compiler.wasm

job             1
entry           /src/hello.mo
files           1
sourcesDigest   bd1434f9c83abd6f0c21843a1a3ebba433a63bff2026fe0a5efd1bf8573a3341
optionsDigest   db700b01e8f9e20ce5ad629775f7529a924826df19c8f95c86cdf7b02d9ef649
compilerVersion 1.14.1
cacheVersion    (unset)
artifact        da33c8358aa785232eeb93c51b695ee24599839cbaf80ef80940ff9b4abee9a1  (61650 B, unlinked)
kernels         (none recorded)

ok    sourcesDigest recomputed from 1 files and matches
ok    canister module hash (from the IC) 9294817c6e9069cbd0e712d0e9dde0ec1b6893d0e7b42d798fa3dd4c8cd772cb
ok    the canister is running ~/.local/lib/moxzi/compiler.wasm

*** 2 check(s) passed ***

The check passes: the canister runs the same compiler.wasm that ships with this release. That's why a local build and an on-chain build of the same source produce the same bytes, and why you can check an on-chain build by building locally. moxzi info shows the hashes of your local compiler and linker:

moxzi info | grep -E '^(compiler|linker|sha256) '

compiler : ~/.local/lib/moxzi/compiler.wasm
sha256   : ee9ee3498fb93ef2f761cd0a3655939434154121243202e4f06f8da158ab6a46
linker   : ~/.local/lib/moxzi/linker.wasm
sha256   : f08e91a28fdd88caf758332cd97ce290c1751dfab45b890a9fbde4f5aea5aaed

A canister's controllers can upgrade it. Check the module hash, not only the canister id, each time you rely on a build.

Check the kernels#

The kernels lines name each native kernel the build linked: its pin and the version, source and commit its package declares. The compiler canister checked the bytes against the pin, but it can't know where they came from. To connect a pin to source, rebuild the kernel from the declared source with moxzi kernel verify and compare. See Check a kernel against its source.

Next steps#

• Publishing to a registry: attach the build record to a published wasm.
• Trust.