Stellar
Contract Source Validation SEP #1573
Replies: 7 comments 26 replies
-
|
I have been using your action for my project and it's great 👍 It's very important for the whole supply chain security that we get that part right. Some comments/suggestions:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed feedback.
The workflow can be relatively extended in the future to execute automatic contract deployment to the network on build. However, this process has a huge a list of potential security concerns which need to be evaluated, addressed, and documented before including this functionality in the continuous delivery pipeline.
This is something definitely worth researching in the future. I'm not sure whether it's possible to resolve contract hash -> IPFS attestation hash relation without a centralized entity since IPFS hashes the content of the attestation data itself.
It requires a lot of work. While I think it's the right path, I'm not ready to spare resources for R&D on this right now.
Yes, it's a security concern. We have to trust a centralized entity (GitHub) that it won't mess up with the code, and we need to trust the workflow itself. I mentioned this in the "Security Concerns" section. Please let me know if it's unclear and I need to elaborate on this.
We cannot include SBOM information directly into the contract itself, but probably can generate it alongside with the contract binary attestation. I'll check this. |
Beta Was this translation helpful? Give feedback.
-
Just to be clear, here I was proposing that you put the OpenAPI schema (or else) that you currently use for your current API. It should be a good starting point as it works.
In the security section you mention the trust into GitHub, but I think here we also need to clearly mention again that the contract is being modified to add some metadata into it. In the top section the description is ok I think, but here we should expand on the security implications of modifying the contract. |
Beta Was this translation helpful? Give feedback.
-
|
👋🏻 This proposal is really important and it's wonderful to see it starting to get use already. I think the proposal bundles together three super valuable things that need more specification, independently:
Why:
1️⃣ Linking built wasms to source code – The proposal achieves this with GitHub Attestations and Sigstore's Rekor (transparency log) 👏🏻. GitHub Attestations are sufficient for proving the wasm to source code link. We know this because it's now a software engineering best practice adopted by other ecosystems (npm, pypi, homebrew). The rest of the proposal provides other guarantees and benefits that aren't critical for proving a link between a binary (wasm) and code. The less we add to this verification process that is bespoke, the more we lean on the software engineering industries best practices, the more we can benefit from development outside the Stellar ecosystem. For example, using common tools like the For the purposes of defining how to verify code, the proposal would be sufficient to set it's scope on: Currently the proposal doesn't indicate how to do (b) or (c), other than use the
The proposal suggests SDF take ownership of the bespoke workflow, but if we reduce the verification proposal to the above, there will be no need for any trust in any workflow owner, other than GitHub. Assuming the use of Rekor in the verification process, GitHub on its own would only be trusted at build time, not at verification time. It would be awesome if the proposal could discuss the sigstore primitives that are being used. Because really this solution is platform agnostic already. A payload is produced, signed, published to the sigtore transparency log (rekor), and if you trust the signer, you can verify the payload. But being most practical I think it's fine if it relies on GitHub APIs and maybe in the future a compatible SEP is written that describes the process at the sigstore layer. 2️⃣ Linking built wasms to home domains – The proposal includes instructions for how to store This 'home_domain' linking could be an independent SEP and doesn't need to be coupled with source code verification. The wasm file home_domain linking may also not be sufficient for all use cases. Not all deployments of a wasm hash should be associated with the same home domain. Contract deployments/instances also need a way to report their home_domain linkage, and so it may be better to do linking at the instance level instead of the wasm file meta level. 3️⃣ A convenient common build process or common build containers – The proposal as written requires the use of a GitHub build workflow where contracts are built in a specific Ubuntu docker image, and attestation/verification requires releasing:
The workflow is opinionated and makes assumptions about how a developer wants to build and release their contracts. In other ecosystems that use attestation, building is not opinionated or coupled to attestation, for e.g.: The workflow expands the surface area of a contract developers risk, because they must be concerned with a third parties action, and the additional third party components that workflow pull in and may be supply chain exploitable. For example: It shifts control away from the developer and requires developers to use a specific approach to releasing and building their applications. Ideally developers can be in full control of their own build and release processes and still be permitted to participate in verification. I think a standard GitHub Action that builds Rust Stellar contracts would be good for the ecosystem, but it seems unnecessary to couple it with source code verification. A standard Docker image for building could further the goal of reproducible builds as another method for making it possible to verify builds. This proposal would need more than what exists here though, such as a fully and truly reproducible build image, and a way to securely link wasm builds back to their build image. That effort is much more likely to be iterative and require more work because reproducible builds in Rust are hard (something @brson has spent some effort on improving ❤️) and building other peoples Rust code is unsafe (because building Rust code executes it on the host). In an example contract repo I've written a build process that I think should be compatible with the verification proposal, because it uses attestation reasonably to prove linkage between a wasm and code. Currently it doesn't show up as verified on stellar.expert because it doesn't use the stellar-expert workflow: In my own learning I wrote a prototype CLI command that verifies the code links to the binary using only the @orbitlens and folks, wdyt? Are there three proposals here we can separate? @tupui given your experience with pypi I'm interested if separating this proposal makes sense, specifically separately 1️⃣ and 3️⃣, given that ecosystem has as far as I can tell. |
Beta Was this translation helpful? Give feedback.
-
|
An attestation links a contract WASM to the corresponding source code. If we acknowledge that the proposal doesn't prevent build-time injections, then there doesn't seem to be any benefit to disallowing custom workflows. The proposal requires the use of a specific workflow, when verification only needs the attestation? |
Beta Was this translation helpful? Give feedback.
-
|
All my arguments are on the table. I'm personally not comfortable with an idea to display in StellarExpert repository links established via attestations built by arbitrary workflows. Not ready to take this responsibility. If you insist on this and it's an SDF position, I'll retract my proposal -- please create a SEP as you see fit. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @orbitlens, I wanted to understand this further and asked an auditor to review the proposal both with (#1573) and without the workflow (#1711), and to provide feedback about the security benefits of requiring the workflow. This was their feedback:
I’m concerned that the workflow creates false sense of security, limits developer flexibility, and could become a supply chain vulnerability vector because of the multiple things the workflow would need to be maintained as doing (e.g. stellar-expert/soroban-build-workflow#2). The benefits of the workflow seem to me to be outweighed by those costs, when it doesn't increase security. But I acknowledge stellar.expert is the one displaying the information, and I'm just looking into this further to fill the gaps in my own understanding of what I'm missing here. Does the auditor’s perspective that the workflow doesn’t add security address the concerns your team had that led to requiring it? Or what are we missing? Would love to discuss further. cc @andreas-osec Please add anything I missed. |
Beta Was this translation helpful? Give feedback.
-
|
My problem with such approach is that it guarantees nothing at all. E.g. the workflow might be set as a reference to another repo via The routine we proposed earlier can't protect from malicious code injections through external dependencies, nor guarantee the build reproducibility in the long run. The only thing it guarantees is that the build process started from a specific repository at a specific commit hash. That's what we can show in the StellarExpert interface. We've been discussing this for months. If we divert from the idea of using a predefined compilation pipeline, I don't see a reason why would we have to jump through all the hoops with attestations. Just put the github repo and commit info into the Honestly, at this point I'm ok with any SDF decision on this topic. It's been more than two years of dancing around this problem. To tell the truth, I'm mentally exhausted and don't want to spend any more time on it. Just merge this pull request and we'll use it in StellarExpert, the only thing I'm asking -- please provide a clear warning in the SEP that source code authenticity is not guaranteed and this information cannot be trusted (my previous formulations in the original SEP draft were relatively mild because of the different approach) or remove my name from the "authors" section, I do not want to be potentially liable for any security incidents. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @orbitlens, In my opinion, both proposals don’t offer more guarantees beyond establishing that the build started from the specific repository, at the specific commit, using the specific workflow or pipeline. I think it’s important to state this explicitly in the SEP, since there is no guarantee that the compiled code was actually produced by the contract code visible on Github. The compilation steps should therefore always be reviewed manually. Regarding which proposal is "best", I believe they are equivalent in terms of security. In practice, the decision comes down to which approach people prefer or feel more comfortable with. About the scenario you described: in most cases, it’s relatively easy to spot when a workflow is maliciously importing an external workflow to hide something. However, even if that’s not obvious, there are still ways to detect that the code has been replaced. Here are a couple of examples for reference:
Since GitHub maintains persistent logs, most tampering attempts will leave traces and should raise flags during the workflow review. That said, I’m more than happy to discuss any additional ideas or considerations I might have missed. To wrap up, I don’t see any reason not to use a predefined workflow if end users/consumers are more comfortable with it. However, based on discussions with the team, the concern isn’t with using a predefined workflow itself, but with requiring it. Mandating a specific workflow can create a false sense of security, whereas allowing flexibility makes it clearer that consumers are responsible for reviewing everything individually, and, lastly, it seems unnecessarily restrictive from a devx standpoint, without offering significant gains. |
Beta Was this translation helpful? Give feedback.
-
|
Separate to my other comment which is more about making changes to the SEP, could SEP go into greater detail about what parts of the attestation, it's payload, etc are used for verification? For example, could it discuss what GitHub APIs are used, what fields out of the in-toto.io/Statement/v1 payload data are verified (e.g. the runtime environment == github-hosted?), and information about if the attestation is verified in the Rekor transparency log (imo it's important this is checked as a way to reduce the surface area of the trust in the provider). |
Beta Was this translation helpful? Give feedback.
-
|
I updated the SEP proposal to include the "Attestation Verification Flow" following @leighmcculloch's advice. We also updated the workflow to remove Docker dependency and the step that sends information to StellarExpert API. Our ingestion engine will be able to retrieve this information directly from the contract, so that's not needed anymore. @leighmcculloch could you please take a look at the workflow before we merge it to the master branch? |
Beta Was this translation helpful? Give feedback.
-
Thanks @orbitlens.
@fnando I don't think the CLI's Something I don't see in the attestation flow, and isn't implemented in the CLI's I think we should add a check for this. Why: By relying on the GitHub API a user confirming build information for a contract is trusting GitHub in two moments: 1. at the time the build was created and recorded, and then 2. for the full time window between then and when their API is queried for data. We can reduce the window of trust down to only that first moment by checking that the wasm hash and payload hash are in the transparency log which will ensure the payload has not been altered over time. @orbitlens @fnando Wdyt? Note that the public Rekor API has an SLO of 99.5%. I think someone needs to go deep on the Rekor API, but as a quick example of how to use the Rekor API to verify the wasm hash and attestation payload hash are present also in that API: For stellar-cli v22.5.0 the Apple Silicon binary available here has the following hash: Collect UUID for the wasm hash from Rekor: Collect Payload Hash from Rekor: Collect GitHub Attestation payload for the wasm hash: Check the GitHub Attestation payload hash matches the payload hash in Rekor: Not exampled here is verifying the payload signature, that might also be worthwhile doing. |
Beta Was this translation helpful? Give feedback.
-
|
Oh one more step that I think needs adding to the verification flow is to verify that the runner was a |
Beta Was this translation helpful? Give feedback.
-
I was relooking at the repo and noticed that these changes are on the |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to move this over the finish line. After a lot of internal discussion, we came to the conclusion that we can simplify the proposal a little bit, without heavily relying on a hosted workflow. I drafted an updated version and would love to have your thoughts, @orbitlens @leighmcculloch. Contract Build Verification SEPPreambleSimple SummaryA toolkit for the verification of the contract WASM build. MotivationStellar doesn't store the source code of contracts in the blockchain, so it may be quite challenging for users to make sure that a contract they are going to invoke is not malicious and behaves as advertised. AbstractThis SEP describes an approach to contract build verification using GitHub Attestations. It provides the ability to display information about the contract that's been deployed and the build pipeline that generated the WASM file. This proposal makes no assumptions on how your WASM file is generated, but requires developers to add a metadata entry to the WASM, as well as making an artifact attestion using GitHub Actions. Once the contract is deployed, anyone can verify and inspect the build pipeline that generated the WASM file. It's important to be aware that this doesn't mean that the contract is safe to use, but it does provide a way to verify how the contract was built, by giving access to the workflow file that was used to build the contract. SpecificationThe verification mechanism relies on the GitHub automation and Attestations build artifacts generated during the automated smart contract compilation. Each attestation contains:
In addition to the source code repository link, the workflow can also store a home domain in the contract to provide a consistent off-chain organization and/or token information resolution using a standard SEP-0001 During the compilation, the pipeline stores a repository address in every compiled contract by adding WASM metadata to the Metadata entries stored in the contract WASM:
Based on this information anyone can verify the authenticity of the smart contract source code, and perform a reverse lookup of the contract information from the organization's domain. Design RationaleCurrently, the pipeline relies on GitHub platform tools and does not provide the toolkit for other platforms, like GitLab or BitBucket. GitHub has the largest market share, so the initial implementation utilized its standard APIs and instruments. In the future, in response to the demand, similar automated workflow can be created for other platforms as well. The Likewise, this SEP and workflow can be extended in the future to execute automatic contract deployment to the network on build. However, this process has a huge a list of potential security concerns which need to be evaluated, addressed, and documented before including this functionality in the continuous delivery pipeline. Attestation Verification FlowSteps to assemble the trust chain between the deployed smart contract and the source code repository:
If any of the above steps fail, the entire attestation verification process fails. Workflow Setup and ConfigurationPrerequisites
Workflow PermissionsIn order to create a release, the workflow needs permissions:
id-token: write
contents: write
attestations: writeExample: Basic workflow using Stellar CLIThe following workflow uses Stellar CLI to build and optimize the contract. ---
name: Build and Release
on:
push:
# 1️⃣ Create a release whenever a new tag like `v0.0.0 is pushed.
tags:
- "v*"
# 2️⃣ Create a release manually from GitHub's user interface.
workflow_dispatch:
inputs:
release_name:
description: "Release Version (e.g. v0.0.0)"
required: true
type: string
permissions:
id-token: write
contents: write
attestations: write
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: rustup update
- run: rustup target add wasm32-unknown-unknown
- run: cargo version
# 3️⃣ Set up env vars that will be used in the workflow.
- name: Set up env vars
run: |
echo "WASM_FILE=target/wasm32-unknown-unknown/release/hello.wasm" >> $GITHUB_ENV
if [ -n "${{ github.event.inputs.release_name }}" ]; then
echo "TAG_NAME=${{ github.event.inputs.release_name }}" >> $GITHUB_ENV
else
echo "TAG_NAME=${{ github.ref_name }}" >> $GITHUB_ENV
fi
# 4️⃣ Set up the Stellar CLI.
- uses: stellar/[email protected]
with:
version: 22.5.0
# 5️⃣ Build the contract and mark the WASM with the current repository.
- name: Build contract
run: |
stellar contract build \
--meta home_domain=example.com \
--meta source_repo=github:${{ github.repository }}
stellar contract optimize --wasm ${{ env.WASM_FILE }}
file=${{ env.WASM_FILE }}
cp "${file%.*}.optimized.wasm" ${{ env.WASM_FILE }}
# 6️⃣ Upload the WASM file to the artifacts.
- name: Upload to Artifacts
uses: actions/upload-artifact@v4
with:
name: hello.wasm
path: ${{ env.WASM_FILE }}
# 7️⃣ Build the attestation for the wasm file.
- name: Build Attestation for Release
uses: actions/attest-build-provenance@v1
with:
subject-name: hello.wasm
subject-path: ${{ env.WASM_FILE }}
# 8️⃣ Make a new release.
- name: Make a new Release
id: release
uses: actions/github-script@v7
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const response = await github.rest.repos.createRelease({
owner: context.repo.owner,
repo: context.repo.repo,
tag_name: '${{ env.TAG_NAME }}',
target_commitish: '${{ github.sha }}',
make_latest: 'true'
});
const { data } = response;
core.setOutput('release_id', data.id);
# 9️⃣ Upload the wasm file to the release.
- name: Upload to Release
uses: actions/github-script@v7
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const fs = require('fs');
const path = require('path');
await github.rest.repos.uploadReleaseAsset({
owner: context.repo.owner,
repo: context.repo.repo,
release_id: '${{ steps.release.outputs.release_id }}',
name: path.basename('${{ env.WASM_FILE }}'),
data: fs.readFileSync('${{ env.WASM_FILE }}'),
});Security ConcernsThis SEP does not create any direct security concerns for the Stellar protocol or ecosystem applications. Since the verification routine relies on the GitHub build automation and attestation mechanism, this approach implies the trust in GitHub’s security. If GitHub security is compromised, it means that verification data cannot be trusted. The possibility of such an event looks very low considering the track records of GitHub and its enterprise backers. Unlike other building artifacts, attestations are stored in GitHub forever (or at least until the code repository is removed). Therefore, if developers decide to remove a smart contract repository, the verification chain may be broken. However, downstream systems (like blockchain explorers) may retain the verification information indefinitely, alleviating such risks. While the build process itself is performed in the virtual GitHub environment shielded from an external access, smart contract developers still can potentially use some subtle techniques to inject malicious code into the contract during the compilation phase. Protecting end users from malicious developer actions is out of the scope of this SEP – the primary goal is to provide unfalsifiable evidences that a contract has been compiled automatically using a particular GitHub repository. Changelog
|
Beta Was this translation helpful? Give feedback.
-
|
Hi. It looks like workflow v0.4.0 still not supported by stellar.expert. Any eta for this? |
Beta Was this translation helpful? Give feedback.
-
|
Hey all, should we try to make a meeting or something to push this forward? |
Beta Was this translation helpful? Give feedback.
-
This is a fair assessment I think. GitHub's attestations as a feature is relatively new (2024?). They're built on open standards from the Sigstore project which is less new but still new (2021?). I do think it would be worthwhile expanding the SEP to demonstrate how to verify the attestation using non-GitHub APIs, which should be possible, but I don't think anything in the SEP today precludes that from happening. What am I missing? |
Beta Was this translation helpful? Give feedback.
-
I don't think the SEP needs to have an opinion or define a hierarchy. It should just demonstrate ways to verify the attestation, hopefully more than one way. If the SEP is relying on GitHub storing something, like the |
Beta Was this translation helpful? Give feedback.
-
|
Putting some context here for my comments on Sigstore. There is a missed opportunity on their end IMHO. They don't want to consider putting the data on-chain and they have a form of private chain on their end with their Rekor. https://blog.sigstore.dev/sigstore-blockchain-vs-transparency-logs-d673ea41a9be/ For the SEP itself, my comment was mostly to have a more open language. I personally read the text as too strict on the link to GitHub. e.g. this I do agree that for now GitHub and Sigstore are good options to recommend. I just would like the text to be more open to try to open so people can still be compliant if they find ways to do these actions without GitHub and Sigstore. Linked to your comment on being able to validate an attestation without GH. |
Beta Was this translation helpful? Give feedback.
-
|
@fnando I just saw the PR got merged!? I thought we were still in discussion? We did not at least openly vote or anything. The proposal should at least have a discussion on the rejected ideas we discussed there. Both @orbitlens and I spent quite some time on this and I am not even talking about the community push we tried to do towards securing the supply chain. |
Beta Was this translation helpful? Give feedback.
-
|
The SEP that got merged is a proposal, even after it is merged it is still a proposal. What got merged is a subset of what got proposed at the head of this discussion, a common denominator of sorts, but it doesn't have to be the only solution, and it doesn't have to be a static solution. My assumption is there's always room for more discussion in these forums about SEPs as a SEPs reality is really only defined by adoption and nothing else, not by its presence in a repo. The thread commented in above seems to have stalled back in June. The most recent discussion from August is here. Imo this discussion isn't closed. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the clarifications and acknowledgment @leighmcculloch 🙇 |
Beta Was this translation helpful? Give feedback.
-
|
Cross-posting due to relatedness: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Contract Source Validation SEP
Preamble
Simple Summary
A toolkit for the verification of the trust chain between contract WASM and its source code.
Motivation
Stellar doesn't store the source code of contracts in the blockchain, so it may be quite challenging for users to make sure that a contract they are going to invoke is not malicious and behaves as advertised.
Abstract
This SEP describes an approach of automated source code matching based on GitHub Actions Workflows and GitHub Attestations. It provides the ability to establish a trust chain from a smart contract deployed on Stellar Network to a specific commit in GitHub repository containing source code of this contract. As a side benefit, this standard workflow streamlines the smart contracts compilation and release process for Soroban WASM runtime.
In order to turn on automatic code attestation, smart contract developers create a simple configuration file in a contract Git repository.
When triggered, this workflow:
Upon successful validation, anyone can retrieve the GitHub repo link from the contract binary and verify the authenticity of the build directly on the contract GitHub repository Attestations page or using a blockchain explorer that supports this SEP. The trust chain can be validated up to a particular point-in-time snapshot of the source code at the given commit used to build the contract.
Specification
The verification mechanism relies on the GitHub automation and Attestations build artifacts generated during the automated smart contract compilation. Each attestation contains:
In addition to the source code repository link, the workflow can also store a home domain in the contract to provide a consistent off-chain organization and/or token information resolution using a standard SEP-0001
stellar.tomlfile.During the compilation, the pipeline stores a repository address in every compiled contract by adding WASM metadata to the
contractmetav0custom sections. Metadata is stored in the contract asSCMetaEntryXDR entry. Downstream systems can retrieve this information directly from the WASM, read repository contents and retrieve corresponding attestation from the GitHub API endpoint:https://api.github.com/repos/<user_name>/<repo_name>/attestations/sha256:<wasm_hash>, wherewasm_hashis the SHA256 hash of the contract WASM binary.Metadata entries stored in the contract WASM:
source_repo=github:<user_name>/<repo_name>- source repository linkexample:
source_repo=github.com:reflector-network/reflector-dao-contracthome_domain=<domain_name>- domain that hosts organization'sstellar.toml(domain name only, without schema or relative path)example:
home_domain=reflector.networkBased on this information anyone can verify the authenticity of the smart contract source code, and perform a reverse lookup of the contract information from the organization's domain.
Workflow Setup and Configuration
Prerequisites
.github/workflows/release.ymlin your repository.Workflow Inputs and Secrets
Basic compilation workflow path:
stellar-expert/soroban-build-workflow/.github/workflows/release.yml@mainThe workflow expects the following inputs in the with section:
release_name(required) - release name template (should include a release version variable, e.g. ${{ github.ref_name }})package (optional) - package name to build, builds contract in working directory by default
relative_path(optional) - relative path to the contract source directory, defaults to the repository root directorymake_target(optional) - make target to invoke, empty by default (useful for contracts with dependencies that must be built before the main contract)Basic workflow for the repository with a single contract
Workflow Permissions
In order to create a release, the workflow needs
id-token: write,contents: writeandattestations: write permissions. Default workflow permissions for a repository can be found at "Settings" -> "Actions" -> "Workflow permissions". It's important to specify permissions on the top level in the.github/workflows/release.ymlconfiguration file itself:Building Multiple Contracts
To build multiple contracts, add a separate job for each contract. The workflow will compile and release each contract independently.
Triggering Build Process Manually
Triggering this workflow manually requires a unique release name prompt. Replace the trigger condition in config and update
release_nameto utilize the value from the prompt.Attestation Verification Flow
Steps to assemble the trust chain between the deployed smart contract and the source code repository:
contractmetav0custom sections.source_repokey. Retrieve GitHubuser_nameandrepo_namefrom the meta value stored in the format described above.https://api.github.com/repos/<user_name>/<repo_name>/attestations/sha256:<wasm_hash>. Parse the response as JSON.attestations[0].bundle.dsseEnvelope.payload. The format follows in-toto.io/Statement/v1 standard. Decode the payload as Base64 and parse resulting string as JSON.subject[0].digest.sha256to match the smart contract hash obtained at step 1.runDetails.builder.idto match the trusted reference build workflow repository address and relative path (https://github.com/stellar-expert/soroban-build-workflow/.github/workflows/release.yml@refs/heads/main).predicate.buildDefinition.resolvedDependencies[0].urito match the GitHub repository obtained at step 4.predicate.buildDefinition.resolvedDependencies[0].digest.gitCommitwill contain the git commit hash at which the attestation has been produced.If any of the above steps fail, the entire attestation verification process fails.
Notes
release_contractjob.Design Rationale
Currently, the pipeline relies on GitHub platform tools and does not provide the toolkit for other platforms, like GitLab or BitBucket. GitHub has the largest market share, so the initial implementation utilized its standard APIs and instruments. In the future, in response to the demand, similar automated workflow can be created for other platforms as well. The
source_repometadata record contains a platform prefix (github:) as an extension point for the smooth integration of other repository hosting providers. In addition, attestations can be also potentially stored on IPFS or other distributed storage to increased the data availability.Likewise, this SEP and workflow can be extended in the future to execute automatic contract deployment to the network on build. However, this process has a huge a list of potential security concerns which need to be evaluated, addressed, and documented before including this functionality in the continuous delivery pipeline.
Security Concerns
This SEP does not create any direct security concerns for the Stellar protocol or ecosystem applications.
Since the verification routine relies on the GitHub build automation and attestations mechanism, this approach implies the trust in GitHub’s security. If GitHub security is compromised, it means that verification data cannot be trusted. The possibility of such an event looks very low considering the track records of GitHub and its enterprise backers.
Unlike other building artifacts, attestations are stored in GitHub forever (or at least until the code repository is removed). Therefore, if developers decide to remove a smart contract repository, the verification chain may be broken. However, downstream systems (like blockchain explorers) may retain the verification information indefinitely, alleviating such risks.
While the build process itself is performed in the virtual GitHub environment shielded from an external access, smart contract developers still can potentially use some subtle techniques to inject malicious code into the contract during the compilation phase. Protecting end users from malicious developer actions is out of the scope of this SEP – the primary goal is to provide unfalsifiable evidences that a contract has been compiled automatically using a particular GitHub repository.
The automation workflow that builds smart contracts is currently hosted by StellarExpert. We suggest transferring its repository ownership to SDF in order to minimize trust concerns.
Implementations
Changelog
v0.3.0- Updated workflow to exclude the Docker image, clarified what attestation fields are used during the verificationv0.2.0- Addedhome_domainmeta, notes on meta XDR and format, design rationale for the GitHub platform lock-inv0.1.1- Defined metadata storage key format explicitlyv0.1.0- Initial draftBeta Was this translation helpful? Give feedback.
All reactions