SEP-0058: Contract build reproducibility#1933
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3219ba0e5a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Pull request overview
Adds a new draft ecosystem proposal (SEP-0058) defining a storage-agnostic vocabulary for recording Soroban contract build-environment and source-identification metadata needed to reproduce and independently verify deployed WASM bytes.
Changes:
- Introduces
ecosystem/sep-0058.mdspecifying build environment fields (bldimg, repeatingbldopt) and source identification fields (source_repo/source_rev,tarball_url,tarball_sha256), plus rationale/security/appendix. - Registers SEP-0058 in the Draft Proposals table in
ecosystem/README.md.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| ecosystem/sep-0058.md | New draft SEP defining reproducible-build metadata vocabulary and an example workflow. |
| ecosystem/README.md | Adds SEP-0058 entry to the list of draft proposals. |
tupui
left a comment
tupui
left a comment
There was a problem hiding this comment.
Thanks for putting this together. I left some suggestions.
| Complementary to | ||
| [SEP-55](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0055.md), | ||
| which uses signed CI attestations instead of independent rebuild. The two | ||
| address the same trust question with different trade-offs and can coexist on | ||
| the same contract. |
There was a problem hiding this comment.
I would rephrase the bit about "same trust question". Rather it attests the provenance of the build. So right now both SEPs are really complementary and I suggest using a stronger wording that they be used in tandem.
Saw the bit in the rational and think it should read like this here as well.
There was a problem hiding this comment.
This SEP isn't dependent on SEP-55, it doesn't require it, but verifiers can of course combine them. I don't think the proposal needs to create artificial dependence. The main point here is that this proposal does not attempt to replace or conflict with SEP-55.
| - **CI provenance**: image attestations (e.g. SLSA-style) proving which CI run | ||
| produced the image, so the image can be traced back to a published pipeline. |
There was a problem hiding this comment.
Only mention of SLSA here, I would add a ref at least.
| registry instead of using the versions pinned in `Cargo.lock`. It is therefore | ||
| reasonable, when reproducing a build, to always include `--locked` even if it | ||
| was not present in `bldopt`. |
There was a problem hiding this comment.
I would use a stronger wording. In this context not sure it would be good to leave any space. Pin all the way.
On bldopt the important component is the version of the CLI. I am specifically concerned about breaking APIs. Which is all good as the CLI's version is pinned.
|
|
||
| | key | description | format regex | | ||
| | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------- | | ||
| | `source_repo` | HTTPS URL of the source repository (typically the origin remote). The `github:<user>/<repo>` shorthand defined by SEP-55 is also accepted so consumers can read values produced under SEP-55; the HTTPS URL form is preferred for new wasms. | `^(https?://\S+|github:[^/\s]+/[^/\s]+)$` | |
There was a problem hiding this comment.
Why restrict to HTTPS? At least we should allow IPFS in everything IMHO. Same on the forge side. I would rather see CIDs in general. I am afraid about specifying too much the regex and then we end up with platforms only supporting a single way with no incentive to do something else.
See some lighter wording below but that's in the rational part which implementations are not going to consider much.
| **Source-repo format alignment with SEP-55.** SEP-55 defines `source_repo` as | ||
| `github:<user>/<repo>`; this SEP prefers an HTTPS URL because it generalizes |
There was a problem hiding this comment.
Arguable, you have a URN vs URL. With naming you might need a mapping on your side with allowed values. HTTPS here is similarly restrictive as now you restrict to a given protocol. Linked to my other comment.
|
@tupui Thanks for the feedback. I'll open a change with the minor wording tweaks and links. The PR is a formality and temporary to get the document in the repo. Let's continue discussion at #1923 so that discussion doesn't become fragmented. Can you start sub-threads on the discussion about the scheme support (https, etc) and pinning (--locked) behaviour you are proposing? |
|
ok no problem. The lock part is less my alley but will definitely open one for the scheme support part 👍 |
What
Propose SEP-0058 (Draft), defining a vocabulary for the build environment information needed to reproduce a Soroban contract's wasm bytes from source.
The vocabulary is two groups of named meta fields:
bldimg(digest-pinned container image) and repeatingbldopt(shell-style flags deviating from the baselinestellar contract buildinvocation).source_repo+source_rev,tarball_url, andtarball_sha256, in conformant combinations covering git, hosted tarballs, and content-addressed source.The SEP is storage-agnostic (fields can live in
contractmetav0per SEP-46, in an on-chain registry, or off-chain). An appendix demonstrates a reproducible build withdocker.io/stellar/stellar-cli.Why
A contract deployed to mainnet is opaque bytes today. Anyone can rebuild from
source and compare hashes, but the build environment required to reproduce a
build (container image, toolchain, flags) isn't well defined or recorded
anywhere, so two independent verifiers have no shared way to reach the same
result.
This SEP is complementary to SEP-55 (attestation-based verification): SEP-55
asks "did a particular trusted CI compile this wasm?", while SEP-0058 provides
what's needed to actually rebuild and compare bytes. A contract can carry meta
supporting both, and verifiers pick whichever path fits their threat model.
Discussion: https://github.com/orgs/stellar/discussions/1923