GitHub Community
Replies: 30 comments 19 replies
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Great resources |
Beta Was this translation helpful? Give feedback.
-
|
nice take |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Okay this looks fantastic!! for an small file it works! but how do I sent a proper file, like for instance a YAML in the payload for creating a blob? |
Beta Was this translation helpful? Give feedback.
-
|
@gabo-urrutia-inditex: I have a rough sample of this, but basically you have to escape newline and double quote characters. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Hi @loujr , how can we use this when we don't control the commit? Like when using Lerna or Semantic Release for automatic versioning and changelog.md changes? This is done by the tool. We checkout the repo by using a token generated by a GitHub App, but how do we make those commits verified? Now we have added the GitHub App to the bypass list (because we force verified commits). |
Beta Was this translation helpful? Give feedback.
-
|
i have the same question, how to make lerna commit signed. any news?. thanks |
Beta Was this translation helpful? Give feedback.
-
|
I was attempting to integrate this process with semantic release and create a GitHub Action for it. However, I discovered that someone had already developed it a few weeks ago: verified-bot-commit So here’s my workflow:
|
Beta Was this translation helpful? Give feedback.
-
|
good tip on that action @basevich! |
Beta Was this translation helpful? Give feedback.
-
|
It would really help adoption if GitHub would provide an action to help sign bot commits which lives under the |
Beta Was this translation helpful? Give feedback.
-
|
just to make it clear - the sha value you are sending on the 3rd step should have been |
Beta Was this translation helpful? Give feedback.
-
|
Hello is it possible to push signed commit with a github app installation token using the git CLI? I'll like to be able to run |
Beta Was this translation helpful? Give feedback.
-
|
No, you need to use the tree API to have it signed, unfortunately. See my Actions workflow for another example: https://github.com/joshjohanning-org/commit-sign-app/blob/main/.github/workflows/commit-sign.yml#L80-L153 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I'm having trouble reproducing this for GitHub enterprise instances. Has anyone tried this approach with a GitHub enterprise instance. I noticed for GitHub.com, the committer information for the created commit looks like the above: "committer": {
"name": "GitHub",
"email": "[email protected]",
"date": "2023-03-06T19:01:13Z"
}and the created commit is verified. However, on GitHub Enterprise, it looks a bit different, and the created commit isn't verified.
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @BolajiOlajide! I just got around to trying this. I was seeing the same thing as you, on my GitHub Enterprise Server instance, my commit from the GitHub App made through this method wasn't signed. But then I also noticed - my web commit was ALSO not signed automatically like it is on GitHub.com: As a GitHub administrator, I then enabled web commit signing by following the docs. It involved me logging into the server via SSH, creating a GPG key, adding that to the server, and creating a new user in GitHub and adding the GPG key. Afterwards, my web commit was signed: And running the steps again from this post on using a GitHub app to sign a commit, it was also signed now as well: Summary: You have to enable web commit signing as a Server administrator for this to work on server. |
Beta Was this translation helpful? Give feedback.
-
|
I just wanted to note for future readers, if you are using the email address for the GitHub App for other processes, there is a format you have to use: That ID ( You can get the user ID of the app via the the API using one of these:
|
Beta Was this translation helpful? Give feedback.
-
|
Preciso entrar wi fi |
Beta Was this translation helpful? Give feedback.
-
|
Hi @loujr @joshjohanning , your solutions has been really helpful 🙏🏼. I tried to replicate the same way to sign tags as well but it doesn't work. # Create signed tag
tag=$(curl -s -H "Authorization: token $token" -X POST \
-d '{
"tag": "'"$version"'",
"message": "Release: '"$version"'",
"object": "'"$new_commit_sha"'",
"type": "commit",
"tagger": {
"name": "'"${{ steps.git-bot.outputs.app_slug }}[bot]"'",
"email": "'"${{ steps.git-bot.outputs.app_user_id }}+${{ steps.git-bot.outputs.app_slug }}[bot]@users.noreply.github.com"'",
"date": "'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'"
}
}' "https://api.github.com/repos/$repo_user/$repo_name/git/tags")
# Get the SHA of the new tag
new_tag_sha=$(echo $tag | jq -r '.sha')
# Create the tag reference with verification
curl -s -H "Authorization: token $token" -X POST \
-d '{
"ref": "refs/tags/'"$version"'",
"sha": "'"$new_tag_sha"'",
"force": false
}' "https://api.github.com/repos/$repo_user/$repo_name/git/refs" |
Beta Was this translation helpful? Give feedback.
-
|
Hey @boomshakar! I'm getting the same thing as you here. Any time you can specify the name and email when creating a Git object via the API, it is not going to be signed. An alternative here may be to use the releases capability within GitHub. A release is just additional metadata on top of a tag (it still requires a tag). Specifically, you can create a release via the API and this will subsequently create a tag, and that tag will be signed. If you no longer want the release, you can delete the release afterwards. Releases (by default) show up on the repo's home page, but you can configure that. Here's an example repo where I created a new release which created me a new signed tag ( Example commands: $ gh release create -R joshjohanning-org/test-sign-tags v1.0.1 --notes "test"
$ gh release delete -R joshjohanning-org/test-sign-tags v1.0.1 --yes
✓ Deleted release v1.0.1
! Note that the v1.0.1 git tag still remains in the repositoryI find it easiest to use the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the swift response @joshjohanning . I tried it using the snippet below but doesn't seem to work with my case. The token that is passed there is that of the github app that i'm using,. name: Create GH Release
description: Automaticaly create a latest github release.
inputs:
token:
description: Github user token.
required: true
bot_app_slug:
description: The GitHub App slug
required: true
bot_app_user_id:
description: The GitHub App User ID
required: true
runs:
using: composite
steps:
- name: Get Tag Information
id: get_tag_info
shell: bash
run: |
# Extract version from the branch name (e.g., "release/v1.0.0" -> "v1.0.0")
TAG=${GITHUB_HEAD_REF#release/}
echo "tag=$TAG" >> $GITHUB_OUTPUT
- name: Create and Push Tag
shell: bash
env:
GH_TOKEN: ${{ inputs.token }}
run: |
NEW_TAG_NAME=${{ steps.get_tag_info.outputs.tag }}
# Create tag through API for signing
gh api \
--method POST \
/repos/${{ github.repository }}/git/tags \
-f tag="$NEW_TAG_NAME" \
-f message="Release: $NEW_TAG_NAME" \
-f object="$GITHUB_SHA" \
-f type="commit" \
-f tagger[name]="${{ inputs.bot_app_slug }}[bot]" \
-f tagger[email]="${{ inputs.bot_app_user_id }}+${{ inputs.bot_app_slug }}[bot]@users.noreply.github.com" \
-f tagger[date]="$(date -u +"%Y-%m-%dT%H:%M:%SZ")" \
--jq '.sha' > tag.sha
# Create tag reference
gh api \
--method POST \
/repos/${{ github.repository }}/git/refs \
-f ref="refs/tags/$NEW_TAG_NAME" \
-f sha="$(cat tag.sha)"
- name: Create Release
env:
GH_TOKEN: ${{ inputs.token }}
shell: bash
run: |
PREV_RELEASE_TAG=$(gh release list --limit 1 | cut -f3)
NEW_TAG_NAME=${{ steps.get_tag_info.outputs.tag }}
gh release create $NEW_TAG_NAME \
--title "${NEW_TAG_NAME}" \
--target "$GITHUB_SHA" \
--notes-start-tag "$PREV_RELEASE_TAG" \
--generate-notes |
Beta Was this translation helpful? Give feedback.
-
|
@boomshakar ahh- I believe the app would need You are using the Are you getting an error message creating the release, or are you just not getting the tag signed? I see you're still creating the tag via the API. For the release creation method I am suggesting, you would want the tag to be created WHEN you create the release. The command should create the tag when it creates the release, if that tag does not exist. I'm suggesting something like this to try: name: Create GH Release
description: Automaticaly create a latest github release.
inputs:
token:
description: Github user token.
required: true
bot_app_slug:
description: The GitHub App slug
required: true
bot_app_user_id:
description: The GitHub App User ID
required: true
runs:
using: composite
steps:
- name: Get Tag Information
id: get_tag_info
shell: bash
run: |
# Extract version from the branch name (e.g., "release/v1.0.0" -> "v1.0.0")
TAG=${GITHUB_HEAD_REF#release/}
echo "tag=$TAG" >> $GITHUB_OUTPUT
- name: Create Release
env:
GH_TOKEN: ${{ inputs.token }}
shell: bash
run: |
PREV_RELEASE_TAG=$(gh release list --limit 1 | cut -f3)
NEW_TAG_NAME=${{ steps.get_tag_info.outputs.tag }}
gh release create $NEW_TAG_NAME \
--title "${NEW_TAG_NAME}" \
--target "$GITHUB_SHA" \
--notes-start-tag "$PREV_RELEASE_TAG" \
--generate-notes
|
Beta Was this translation helpful? Give feedback.
-
|
Ooh. I read in a documention to always create tags before creating a release. Thanks @joshjohanning |
Beta Was this translation helpful? Give feedback.
-
|
Great! 😄 @boomshakar Glad to help. |
Beta Was this translation helpful? Give feedback.
-
|
Uploading blobs with Github API comes with a limit of <40 MiB, but it's easy to circumvent. Just create your tree and blobs with regular git, push to a temp branch and create a new verified commit from the uploaded tree: # Create a commit normally.
git add big-file1 big-file2
git commit -m "temp"
# Get tree hash locally. If you get it from GH API theoretically someone could
# front-run your request and push an evil commit on top of the branch,
# and then your bot would sign it.
TREE_SHA=`git log --format=%T | head -n1`
# Push to github, this creates the blobs and tree you can later access by API.
# Github doesn't delete anything (at least not right away) when you remove the branch.
git push origin HEAD:temp-branch && git push origin :temp-branch
# Create verified commit as your app with large files!
gh api -X POST repos/<team>/<repo>/git/commits -f "message=Verified commit with large files!" \
-f "tree=$TREE_SHA" -f "parents[]=<parent commit hash>"
# Update branch ref.
gh api -X PATCH repos/<team>/<repo>/git/refs/heads/<branch> -f "sha=<new commit hash>"This probably gets you LFS for free too, though I haven't tested. |
Beta Was this translation helpful? Give feedback.
-
|
Great tip! Thanks for the example. |
Beta Was this translation helpful? Give feedback.
-
|
This explanation is very clear and well-written. It appears that this process will require three API calls, plus an additional call for each file you are attempting to modify (to create the blob), correct? I anticipate performing this operation frequently across hundreds or even thousands of repositories, and I am concerned about encountering rate limits. Has rate limiting been factored in, as this can easily be executed as a Git operation and does not contribute to the API rate limits? |
Beta Was this translation helpful? Give feedback.
-
|
@bmeverett You should be able to edit multiple files in the same repo with the tree API. But yes, minimum 3 APIs per update. That means using a GitHub App installed in an Enterprise, you can make a maximum of 5,000 edits per hour (15,000 max rate limit / 3 calls = 5,000). If you use the Git client to edit files, you don't have to worry about API rate limits (but won't be able to sign the commits from the App). There is an update contents API as well, but same thing, won't be able to sign the commit. |
Beta Was this translation helpful? Give feedback.
-
|
@joshjohanning Thanks for the info! Are there any plans to improve this and allow a Git client sign commits as an app? |
Beta Was this translation helpful? Give feedback.
-
|
@bmeverett I would say the above 👆 is the solution - nothing coming client side unfortunately. If you have that many files you are frequently changing across hundreds/thousands of repos, I am kind of curious as to your use case - but otherwise, sharding it with multiple GitHub Apps is probably the best bet if you are concerned about the rate limit currently. |
Beta Was this translation helpful? Give feedback.
-
|
@bmeverett also note, that if the repositories span across several organizations, each organization (installation) has its own rate limit. That might help too! |
Beta Was this translation helpful? Give feedback.
-
|
Good post, upvoated +1 👍 |
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.
-
How do you know that someone has not tampered with your code and pushed in a lot of commits claiming to be someone they're not? A verified commit is a signature on the changes you have made to your codebase. Commit signing provides a tamper seal that adds an extra level of assurance that the person who committed changes to a repository is the person they claim to be. This signature can be signed multiple different ways such as GPG, SSH, or S/MIME. If this signature is present, GitHub will mark this commit as verified.
Why would anyone need to sign a commit using a bot? Maybe your organization has a tightly controlled codebase that needs to be audited and commits need to be from verified sources. Maybe your CI/CD infrastructure has a lot of branch protection requirements and requires verified commits. Additionally, you might have a lot of contractors filter in and out of your organization. This functionality could also be a tool of last resort if your verified chain is broken or compromised in some way. This feature allows your development team to submit changes to your codebase and have a trusted third party integration verify authenticity of the origin of these commits.
Outlined in this article is a step by step process of uploading a file to a repository and having the commit signed by a GitHub App. In this example, we will be using app-evil-corp bot to sign commits on our test repository on behalf of Evil Corp our favorite fictional corporation from the show Mr. Robot.
In order to set up GitHub App commit signing. You first must create and install a GitHub App and obtain a GitHub App Installation Token. For more information on how to create a GitHub App, please check out Creating a GitHub App and Installing GitHub Apps for GitHub App installation instructions. To obtain a GitHub App Installation Token, please check out the community article GitHub App Installation Token and Authenticating as a GitHub App.
There are three steps to using GitHub App commit signing:
Creating a Tree
A tree is an object that allows you to create a hierarchy between files in a git repository. Without a tree, there is no way to associate all the tracked blob files and their contents. Blob is just a fancy way of saying its a whole bunch of compressed data (using zlib) and stored in an object database. A tree is really an index of all that information that explains which corresponding file belong to which directory.
To create a tree, curl the following endpoint Create a tree. For GitHub App commit signing, the following parameters are needed:
base_tree- This is the SHA of the branch you have made your commit. In this example, this SHA is the last commit sha for the main branch of test repositoryrepo-test555.tree- build's a new tree object on this branch requires an array of objectspath- file that you are referencing in this treemode- permissions of the file referenced in your tree can be one of100644for file (blob),100755for executable (blob),040000for subdirectory (tree),160000for submodule (commit), or120000for a blob that specifies the path of a symlink.type-blob,tree, orcommitcontent- the content you want the file to have. GitHub will write this blob out and use that SHA for this entry. Use either this, or tree.sha.Note: To find the full SHA of your last commit, you can look at the commits history of your repository. To copy the SHA, click the square next to the commit that says: Copy the full SHA
In this example, the file
helloworld.pywas uploaded with the permissions644to repository Repo-Test555. The file is a blob file and contains the messagehello world.The following response was received after making this API call. A tree object was created containing the contents of
repo-test555.Note: The SHA response
b12fd1716b81a52f233940c82ab67f6500238701is critical for making a commit. Please retain this value in your response.Create a Commit
After a new tree is created, a new commit must also be made. This commit contains both the commit message as well as the SHA of the new tree and the SHA of the base branch. To create a Commit, curl the following endpoint Create a Commit. Using a GitHub App Installation Token will skip the need to specify a GPG Key, instead GitHub will sign the commit using their GPG Key through the GitHub App. To use GitHub App commit signing, you will need the following parameters:
message- The commit message of verified commitparents- The commit SHA of the branch you made your commitstree- The SHA that was returned after you created your new treeOn the response, you can see the
verificationobject. This object contains theverifiedkey which is a boolean value. If the value istrue, the commit was verified. If the value isfalse, the commit was not verified. Further, the GPG signature is included in thesignaturekey. Because you have used the GitHub App Installation token, GitHub is able prove that you have access to this GitHub App and uses their (GitHub's) GPG key to sign the commit.Note A the time of making this commit, the commit is not referenced in the
mainbranch. It exists as a commit on a fork outside of the repository until we update the reference. This is apparent when you view thehtml_urlof the commit.Update a Reference
Updating a reference is a final step in the process of using GitHub App Commit Signing. We take our newly created tree and our new commit and we associate the two together. Once we add the commit to our newly formed tree our bot is going to see the GitHub App Installation Token, it will say "looks good to me" and then give us the seal of authenticity. To create this reference we need the SHA value for our new commit. To update a reference, curl the following endpoint Update a Reference remember to use the SHA value response from making your commit.
SHA- Response from theCreate a Commitendpoint.Congratulations you have signed a commit using GitHub Commit Signing! You can check out more about GitHub Commit Signing here. To display verifcation statuses for all your commits, read About Vigilant Mode.
Beta Was this translation helpful? Give feedback.
All reactions