runner
runner copied to clipboard
actions
Support Signed Commits by [email protected]
Currently if "signed commits" are required in branch protection there is no good way to have actions update code using the token provided for use with github actions and the current repository. Seems like github actions should provide a way for changes made by [email protected] to be signed and show as verified through the interface.
I have been using the following action. Once the action runs any git commands in following steps will use the signature. It does require storing secrets with GPG info though.
- name: Import GPG key
id: import_gpg
uses: crazy-max/ghaction-import-gpg@v2
with:
git_user_signingkey: true
git_commit_gpgsign: true
env:
GPG_PRIVATE_KEY: ${{ secrets.GITHUB_ACTIONS_GPG_KEY }}
PASSPHRASE: ${{ secrets.GITHUB_ACTIONS_GPG_PASS }}
@timharris777 Even if you use the above GitHub action, it doesn't work with [email protected] right? I can confirm it works with my personal email address. If I export a secret using [email protected] it still shows as unverified in the GitHub web UI.
@timharris777 Even if you use the above GitHub action, it doesn't work with
[email protected]right? I can confirm it works with my personal email address. If I export a secret using[email protected]it still shows asunverifiedin the GitHub web UI.
@atreya2011 , yes you are correct. But we created a service account just for github actions that we then use to sign commits. It's the best thing we could do until github supports this.
@atreya2011 , yes you are correct. But we created a service account just for github actions that we then use to sign commits. It's the best thing we could do until github supports this.
Thank you for the confirmation @timharris777! By a service account do you mean that you created a new user account? That would be adding a seat and getting charged 4 USD a month.
@atreya2011 , yes you are correct. But we created a service account just for github actions that we then use to sign commits. It's the best thing we could do until github supports this.
Thank you for the confirmation @timharris777! By a
service accountdo you mean that you created a new user account? That would be adding a seat and getting charged 4 USD a month.
That's correct. It is just a new user account that unfortunately takes up a license.
That's correct. It is just a new user account that unfortunately takes up a license.
Very unfortunate that this seems to be the only way now. Hope GitHub supports signed commits by [email protected] soon 🙏🏼
We created a centralized process with terraform to manage our github repos - it was working great until we enforced signed commits as part of this. Now we're stuck with either removing the security feature entirely or using a workaround.
Please support verified commits with github actions!
Hey all, I hope you are doing well. @timharris777, thanks for sharing your experience, it actually enabled us to follow in your footsteps and deploy the same strategy!
Is there any traction at all from github? This is crucial for us as signed commits have been made mandatory for our repositories and creating and managing non-human accounts is not really trivial. In my eyes signed commits need to be supported by github actions directly rather than us having to jump through hoops.
What's the cryptographic purpose for this?
If any action can create signed commits under [email protected], then what does the signature indicate, that the commit was made on GitHub Actions rather than on humans' local machine?
The actual feature we should propose is to recognize [email protected] as a non-human account associated with me, and can be verified by my GPG keys. All I need is to store a private key as actions secret and use it for signing the commits.
+1 This would be really helpful. Compromising on security by disabling the branch protection rule isn't a good workaround but in order for people to use Actions with various automation scenarios, this is really needed.
I'm collecting all the information I found about this topic on this repo/article: https://github.com/josecelano/pygithub/blob/main/docs/how_to_sign_automatic_commits_in_github_actions.md I've also added some examples.
@josecelano An excellent write-up summarizing the current state of things. I am bookmarking this 🙇🏼♂️
What's the cryptographic purpose for this? If any action can create signed commits under
[email protected], then what does the signature indicate, that the commit was made on GitHub Actions rather than on humans' local machine?The actual feature we should propose is to recognize
[email protected]as a non-human account associated with me, and can be verified by my GPG keys. All I need is to store a private key as actions secret and use it for signing the commits.
Signing a commit is not only meant to tell you that someone is the author of that commit, it's also meant to tell you about the integrity of the commit and that it hasn't been tampered with.
I would be ok with having an official action that takes a GPG key and sets it up to sign commits automatically, I'm doing the same thing in my repositories but manually, your idea of having a [email protected] is interesting, but the same can be accomplished by adding just adding a new email to your account and uploading a new GPG key to your account that references the same email so that anything signed by that key appears as verified.
The easiest solution would be to just have an option to allow unsigned commits (or unverified keys) coming from GH Actions to go around the signed-commits setting for the branch.
I would be ok with having an official action that takes a GPG key and sets it up to sign commits automatically, I'm doing the same thing in my repositories but manually, your idea of having a
[email protected]is interesting, but the same can be accomplished by adding just adding a new email to your account and uploading a new GPG key to your account that references the same email so that anything signed by that key appears as verified.
The main purpose of [email protected] is to display the commit author as "me [bot]" rather than "me", without creating a new account called me-bot.
It would be great to see this feature included, we're running into this at the moment.
FYI there's a workaround that worked for me https://gist.github.com/swinton/03e84635b45c78353b1f71e41007fc7c
I replaced DESTINATION_BRANCH with ${{ github.ref }} to commit to the current branch.
FYI there's a workaround that worked for me https://gist.github.com/swinton/03e84635b45c78353b1f71e41007fc7c
I replaced DESTINATION_BRANCH with ${{ github.ref }} to commit to the current branch.
if you're running it from a PR, it should be ${{ github.head_ref }}
Any response from GitHub enterprise customers?
This would be a big +1 for our Enterprise, yes!
This is really needed. Has anyone contacted Github through their enterprise support portal? Unfortunately Github doesn't really care this kind of issues. They probably never seen this issue unless it's brought up to their face.
FWIW this is the solution we've implemented. https://httgp.com/signing-commits-in-github-actions/
I did kinda the same, but I needed to create a PR, so the usage of the GPG key is a bit different: if that can help others, check https://github.com/kubefirst/docs/blob/main/.github/workflows/release.yml .
Commits generated through the GraphQL API's createCommitOnBranch mutation are signed by github's web-flow GPG key. We created ghcommit and ghcommit-action to take advantage of this in our GHA workflows (and avoid GPG keys in GHA).
@joemiller Thanks so much for pointing that out. That works beautifully for us! 👏🏼
I have an example of using the createCommitOnBranch mutation of the GraphQL API here.
script/ci_commit_with_signature.sh
https://github.com/maboloshi/inuyasha/blob/main/script/ci_commit_with_signature.sh
#!/bin/bash
TOKEN=$1
repoNwo=$2
branch=$3
# The SHA of the last commit on the remote target branch
expectedHeadOid=$4
file_path=$5
encoded_file_content=$(base64 < "$file_path")
message_headline=$6
message_body=$7
curl "$GITHUB_GRAPHQL_URL" --silent \
--write-out '%{stderr}HTTP status: %{response_code}\n\n' \
-H "Authorization: bearer $TOKEN" \
--data @- <<GRAPHQL | jq
{
"query": "mutation (\$input: CreateCommitOnBranchInput!) {
createCommitOnBranch(input: \$input) {
commit {
url
}
}
}",
"variables": {
"input": {
"branch": {
"repositoryNameWithOwner": "$repoNwo",
"branchName": "$branch"
},
"message": {
"headline": "$message_headline",
"body": "$message_body"
},
"fileChanges": {
"additions": [
{
"path": "$file_path",
"contents": "$encoded_file_content"
}
]
},
"expectedHeadOid": "$expectedHeadOid"
}
}
}
GRAPHQL
GitHub action section .github/workflows/CI.yml
https://github.com/maboloshi/inuyasha/blob/main/.github/workflows/CI.yml
- name: Commit file KeepAlive.txt
run: |
bash script/ci_commit_with_signature.sh \
${{ secrets.GITHUB_TOKEN }} \
${{ github.repository }} \
${{ github.ref_name }} \
${{ github.sha }} \
"KeepAlive.txt" \
"KeepAlive.txt Update to version $(TZ='Asia/Shanghai' date +'%Y-%m-%d')" \
"Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>"
GraphQL API can not set the 'author' or 'committer' account, it automatically uses the account to which TOKEN belongs, when using GITHUB_TOKEN the corresponding account is github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>, if you use PAT or Fine-grained PAT, the corresponding account is the person to whom TOKEN belongs.
If you use PAT or fine-grained PAT, you can also bypass the branch protection rule. (#25305)
