ci: read the !build comment body from env instead of interpolating it - #4389
Open
kobihikri wants to merge 1 commit into
Open
ci: read the !build comment body from env instead of interpolating it#4389kobihikri wants to merge 1 commit into
kobihikri wants to merge 1 commit into
Conversation
This file contains hidden or 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.
Hi, and thanks for Graphite.
In
.github/workflows/comment-!build-commands.yml, the!buildcomment is read into the shell like this:Actions expands
${{ ... }}into the script text before bash runs, so the comment body becomes part of the script rather than a string assigned toCOMMENT. A comment body is completely free text, and$(...)and backticks still run inside double quotes — so!build $(...)would execute on the runner instead of being parsed as a target argument.You have already thought about the security of this workflow, and I want to acknowledge that rather than talk past it. The job is gated on:
github.event.comment.author_association == 'MEMBER'with a comment explaining exactly why. That is a real control and it means this is not open to the public — it needs an org member. So I am raising this as defence in depth, not as an open door: it matters if a member's account is compromised, and it removes a sharp edge where a member's comment can do something they did not intend.
The change binds the body to an environment variable, which is the fix from GitHub's own hardening guidance:
Everything downstream is untouched —
read -ra WORDS <<< "$COMMENT"and the!build/ target / profile parsing all behave exactly as they do today. Two lines added, one changed.Disclosure: I used AI assistance to help spot this and prepare the change, and I read the workflow and its membership gate myself.