Experimental contract verify command #1778
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Add a
contract verifycommand that implements a subset of @orbitlens proposal:Try it out
Example
The leighmcculloch/exp-stellar-expert-verified-builds repo contains a contract that has been built by the
stellar-expert/soroban-build-workflowas well as a custom workflow that uses the attestation principles but not the stellar-expert build process.Contract built with
stellar-expert/soroban-build-workflowdeployed to CBLB:Contract built with
custom-release.ymldeployed to CCDI:Why
This change is an experimental implementation of a subset of the proposal to explore how other tooling might use the data and attestations published to confirm what code was the source of deployed wasm contracts.
The proposal includes principles for how to use GitHub's Attestation feature, based on Sigstore, to confidently link source code in a repository and a workflow run that builds an artifact, to a hash of the artifact. These principles are what's implemented in this change.
The proposal also includes details for how to use a third party GitHub Action
stellar-expert/soroban-build-workflowworkflow and build process to build contracts in a specific docker container and using specific actions, but the verification logic in this command at this time does not depend on those aspects of the proposal.For more details on why this change implements only a subset, see the discussion here:
Known Limitations
The verification logic was hacked together quickly and a final implementation should involve a thorough understanding and review of https://in-toto.io/Statement/v1 payloads and all the edge cases that could arise and should be caught.
Additionally it would be ideal if the payload signature was verified in Sigstore Rekor (transparency log), and that the payload could be optionally provided on the command line instead of downloaded via GitHub, because that would theoretically allow any sigstore in-toto attestation to be verified, not only GitHub's.
Status
As this change is an experiment it is not intended to be merged, not at least without significant additional work. It will remain in a draft state to be used to drive discussion.