Open timharris777 opened 4 years ago
Yes, agreed. This is needed.
+1
Does anyone have a workaround for this?
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 actions@github.com
right? I can confirm it works with my personal email address. If I export a secret using actions@github.com
it still shows as unverified
in the GitHub web UI.
@timharris777 Even if you use the above GitHub action, it doesn't work with
actions@github.com
right? I can confirm it works with my personal email address. If I export a secret usingactions@github.com
it still shows asunverified
in 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 account
do 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 actions@github.com
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.
Any response from GitHub enterprise customers?
What's the cryptographic purpose for this?
If any action can create signed commits under actions@github.com
, 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 myname+actions@github.com
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
actions@github.com
, 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
myname+actions@github.com
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 me+actions@github.com
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
me+actions@github.com
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 me+actions@github.com
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! 👏🏼
@joemiller, thanks for ghcommit-action. Work flawlessly
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
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
```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)
I'm not sure where I found this awesome solution using GitSign, but I think it should be noted here!
I'm not sure where I found this awesome solution using GitSign, but I think it should be noted here!
Thank you for pointing that out, @mogul, because it helps with signing. Unfortunately, I use that solution, but it doesn't show as verified.
Maybe because the certificate is only around for ten minutes...? I don't know. But if it's verifiable long enough to help pass branch protection rules requiring signed commits, that seems worth it.
I'm not sure where I found this awesome solution using GitSign, but I think it should be noted here!
Thank you for pointing that out, @mogul, because it helps with signing. Unfortunately, I use that solution, but it doesn't show as verified.
@gmeligio It's documented on their README:
https://github.com/sigstore/gitsign?tab=readme-ov-file#why-doesnt-github-show-commits-as-verified
Thank you @josecelano and @mogul for your comments. I'm not sure if I read it before there or just stopped at chainguard-dev/actions/setup-gitsign
README. But for sure, I didn't understand the "short time" part. Now I see why it isn't verified. Let's hope Github can improve the integration with Gitsign, as they say that the verification part is on the GitHub side.
Especially since https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/ it would be nice for gitsign verification support for commits.
Proposal: a .github/authorized_keys
file to verify commits
Say I want to change the version number in a GitHub Workflow, similar to this:
steps:
- uses: actions/checkout@v4
with:
ssh-key: ${{ secrets.SIGNING_KEY_PRIVATE }}
- uses: pnpm/action-setup@v2
with:
version: latest
- name: Configure Git, patch, release and push
run: |
git config user.name 'github-actions[bot]'
git config user.email '41898282+github-actions[bot]@users.noreply.github.com'
git config commit.gpgsign true
git config gpg.format ssh
git config user.signingkey 'key::${{ vars.SIGNING_KEY_PUBLIC }}'
eval `ssh-agent -s`
ssh-add - <<< '${{ secrets.SIGNING_KEY_PRIVATE }}'
VERSION=$(pnpm version patch --no-git-tag-version)
git commit --all --message "🔖 $VERSION"
git tag --annotate --message "🔖 $VERSION" --sign $VERSION
git push
git push --tags
There's not really a good way to attribute this commit to an imaginary "GitHub Workflow" user. In any case, I'm using github-actions[bot]
to be able to see its little profile picture in the list of commits and I'm signing this commit to be able to verify it later.
This works wonderfully, except that the signature doesn't actually belong to that account.
What if there was a way for repositories to mark these commits as verified? For example, GitHub signs commits I make with GitHub's signature, not mine, so there's already some switcheroo going on behind the scenes.
Proposal: .github/authorized_keys
file.
Similar to CODEOWNERS
, a file that would allow specifying that some commits can be signed by a specific signature.
41898282+github-actions[bot]@users.noreply.github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMkNA810FaHR9kOJmJthn1XAAqydaOQIwvJ2KfTWD2ti @natoboram/leanish
This file should be compatible with Git's ways of verifying signatures with this kind of files (AUTHORIZED_KEYS_FILE_FORMAT). Here's some docs on the subject:
I created an action to create signed commits the beauty of this action it's just an drop-in replacement of git commit
you still can use the git push
command as you're used to. Feel free to have a look at https://github.com/qoomon/actions--create-commit
I've updated create-pull-request to support commit signing with bot-generated tokens (GITHUB_TOKEN
or GitHub Apps). It might help for some use cases.
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
actions@github.com
to be signed and show as verified through the interface.