From Monday 16th March we will be requiring Git signed commits for all repos under github.com/ansible/.
Red Hat is continually looking at improving the supply chain, so expect further improvements as Ansible adopts more of the Cyber Resilience Act (CRA), updates will be shared in the Ansible Forum under the infra-and-security tag.
FAQ
How do I setup Git Signed Commits?
You can use either GPG or your existing SSH key to sign commits:
git rebase --exec 'git commit --amend --no-edit -S' -i main
git push -f origin my-feature-branch1
What about the other GitHub organisations, such as ansible-collections and ansible-community?
We will roll this improvement to the other Ansible related GitHub organizations soon, so please make the time to setup signed commits to avoid needing to rebase existing PRs in the future.
What other improvements are likely?
The Cyber Resilience Act (CRA) is giving us a chance to review our existing processes. Expect improvements to:
GitHub Rulesets to protect branches and require PR reviews
Ouch.. Looks like we just got hit by this — it broke a part of the (post-)release process in ansible/pylibssh
There’s a changelog generation commit that is made during an automated release in a separate branch as a part of the CI/CD pipeline (behind a human approval of the , of course). That commit gets tagged and corresponds to the released artifact. This is in the release branch that also gets a PR open. After the pipeline completes, it’s required that the branch is merged using the “natural” method (not fake “merges” like rebase or squash) — this means that the individual commits of that branch would become a part of the main development branch. Including the tagged commit (so the tag will “belong” to devel in the end). This is mandatory to make the Git-based version computation work correctly, meaning that until it’s figured out, it’ll block any development in the project (well, we won’t be merging any PRs at least).
@webknjaz Thanks for reporting this, sorry we broke your workflow.
I’m not familar with the workflow we have on pylibssh though some options could include:
Only restricting the default branch (though if it’s #828, then looks like you are merging into devel)
Add an allow for this specific bot user (though unsure if we can rename the account)
Yep, the new ruleset only applies to the default branch. Basically, when you git merge one branch into the other, two chains of (kinda parallel) commits become a part of that target branch. GitHub sees this as pushing those individual commits from the incoming branch into devel. Said commits are made in the CI environment with the GitHub Actions user as the commit author, pushed into the branch via GITHUB_TOKEN GHA provisions (though, ther auth bit is irrelevant here). These commits are unsigned and so merging them in is seen as “pushing unsigned commits into devel (the default branch)”, which ends up rejecting the push.
There’s not “user”. The commit metadata lists whatever author you tell Git to put in there. The metadata fields (and contents) are basically arbitrary strings. In order to sign the commits, we’d need an actual user, I imagine (I wonder if OIDC would be helpful here, though). And we’d need to set that user email as the committer/author, plus in addition to that, sign the commit. This means stuffing the user’s private signing key into the repo secrets (if it doesn’t fit into a secret, then maybe committing an encrypted key, like the the times of Travis CI, and only putting the decryption key into the secrets).
It looks like it may take some time to figure out how to move forward long term.
Right now, we have a project with a half-complete release process that cannot move forward until a proper merge happens. And force-pushing the branch with signed commits isn’t an option because the tag will keep pointing to the unsigned commit and tags are supposed to be immutable, not force-pushed to point to new commits on a whim.
So short term, we’ll need to somehow disable this blocker to get the PR in. Like maybe coordinate it for a few minutes and re-enable.
UPD: the problem’s got solved somehow. @gundalow did you change the configuration or was it the fact that I initialted merging from the GitHub UI rather than command-line locally? Looks like @sivel helped with that.
Eh? You must add the key a 2nd time as signing key? and there is no verification step?
On Gitea, you get a verification step to proof that you’re also the owner of the private key
@gundalow another broken use case I’ve hit in ansible/awx-plugins and ansible/awx_plugins.interfaces is generating lock files in CI (avoiding third party services) and submitting a PR with unsigned commits (with human approval).
Right.. I was expecting that to happen in the docs repo but haven’t been watching it closely lately so didn’t really check.
Not sure I like sticking secrets into GHA envs either. I’ll have to spend some time tinkering but one seemingly usable idea would be relying on OIDC, I imagine. This would require having a GH App deployed, of course.
Hi folks,
I appreciate all the feedback, there are clearly more edge cases than we realised, so please do continue to share specific feedback so we can make targeted improvements.
We do not want to make contributing to Ansible more difficult than it needs to be.
We won’t be required signed commits on the ansible-community & ansible-collection orgs at this time.
We have the ability to enable this requirement on a per-repo level, which is something we might consider.
Just realized that anything using my Patchback bot is going to be affected too. I’ve been meaning to look into implementing signing in there but it was never a top priority but rather a fancy thing to experiment with. In fact, the tracking issue is the very first one in the bot repo, filed 5+ years ago. Not sure when I’ll get to it but How to Use Commit Signing with GitHub Apps · community · Discussion #50055 · GitHub seems to even go over hacking silly limitations of GH API.
