Check that the gate's build is reproducible, across Stellar CLI versions
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 62/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- github-actions, rust, wasm
- Domain
- build-system, ci-cd
Research direction
Start with evidence/README.md (the recorded hash and CLI version) and the build job in .github/workflows/ci.yml (stellar-cli 28.1.0). Build the gate with both CLI versions and diff the WASM bytes to confirm that only the contractmetav0 cliver entry differs. Then write a small comparison script that ignores that entry and reports identical, identical-apart-from-CLI-version, or different, with tests on synthetic WASM files. Done when all three outcomes are tested and CI passes with the CLI version it uses.
Written by the indexing model from the issue text.
Description
Written against commit a23a8df; later commits may have moved things, so check the code first.
Size: Medium
Description
evidence/README.md records the gate's WASM hash, and nothing checks that a fresh build still produces it. Worse, the recorded
hash and the hash CI builds are already different, and the repository does not say so.
Current state
evidence/README.md records the gate as 3,544 bytes with sha256 9885f2a8b5a0710299a50391fb36667da0b3c856dbadd8508a48f29095bb48d6,
"built with stellar-cli 27.1.0". The build job in .github/workflows/ci.yml uses stellar-cli 28.1.0, and on the run for
commit bbd5a8e it printed the same size but a different hash: fcd9276d804b587df7522c42747a270318795c6f67870714dba8e2acbd3e4eb2.
Sorogate's own repository found the same effect for its policy contract: the Stellar CLI stamps its own version into the WASM's
contractmetav0 section (an entry called cliver), so two CLI versions give files that differ only there. Sorogate's
packages/sdk/scripts/wasm-identity.ts has code that compares two builds while ignoring that one entry. Nothing in this
repository does, so a reader who rebuilds with a different CLI sees a mismatch they cannot explain, and a real change to the
gate would not be distinguishable from a CLI upgrade.
What to build
- Confirm the explanation: compare the two builds and show that only the
clivermetadata differs. - Add a check, in CI and as a script, that builds the gate and compares it with a recorded hash while ignoring the CLI-version
entry, and says clearly which of three things happened: identical, identical apart from the CLI version, or different. Keep
it small and keep this repository independent: reimplement the comparison here rather than depending on Sorogate's code. - Record the hash in one place that the evidence, the README and the check all use.
Acceptance criteria
- The PR shows the byte-level difference between the 27.1.0 and 28.1.0 builds and that it is only the CLI version.
- The check reports the three outcomes, with a test for each (using small synthetic WASM files).
- CI runs it, and it passes on the current code with the CLI version CI uses.
- Changing a line of the gate makes it report "different".
-
evidence/README.mdand the README state which CLI version each recorded hash came from.
Out of scope
Pinning a particular CLI version for everyone. Publishing the gate's WASM anywhere.
Verification
The new script's tests, and the PR's CI run.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 2
- Avg merge
- 49m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Sorogate/example-consumer
-
documentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Sorogate/example-consumer#17 ·
-
documentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Sorogate/example-consumer#16 · 1 comment · 1 reaction ·
-
documentation good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Sorogate/example-consumer#15 ·
-
enhancement good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Sorogate/example-consumer#14 ·
-
enhancement good first issue help wanted
Difficulty 2/5 Half a day Newbie friendliness 80/100
Sorogate/example-consumer#12 ·
All issues in Sorogate/example-consumer
Similar issues
-
defect
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 2 days
-
enhancement user-priority/P3
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day