-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Committer verification #2770
Comments
From git point, I would recommend you to use gpg commit verification (allready implemented) that allow a "pusher" to push commit from another "commiter" and still be able to verify that the commit hasn't be tempered or that the identity of the commiter ins't falsify. This type of verification is totally decentralized and verification can also be done locally and is supported natively by git. This solution, doesn't cover the part of only allowing to push commit from the logged user that maybe needed for your corporation (this would block cherry-pick and some git flow if enable). If the gpg method doesn't fully comply with your need, gitea support server-side hook but those need to be added manually via git cli. More generaly, we could provide a way to apply predifined list of server-side hooks. EDIT: it is also possible to edit the pre-receive hook via web interface. |
So maybe we could have an option on repository setting to deny all push gpg verify failed. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions. |
Does gitea pass any user info through environmental variables? That would allow these hooks to work. |
Yes it does. Lines 187 to 195 in ee1d64d
However read my comments on #8584 It can be done we just need to do a bit more work. |
For simple committer verification this works work well in Gitea v1.9.5: #!/bin/sh
err(){
>&2 echo "Pre-receive validation: $*"
}
hasErr = 0
while read oldrev newrev ref
do
if [[ "$oldrev" == "0000000000000000000000000000000000000000" ]]; then
#create new branch
continue;
fi
export committers="$(git log --format="%H %ce" $oldrev..$newrev)"
while IFS=' ' read -r commitHash committerEmail;
do
if [[ "$committerEmail" != "$GITEA_PUSHER_EMAIL" ]]; then
err "You are not $GITEA_PUSHER_EMAIL! You pushed commit $commitHash as $committerEmail"
exit -1
fi
done <<< $committers
done
exit 0 This verifies every pushed commit against the Gitea users e-mail address. Indeed, gpg signing might be more perfect, but this does work.
|
@Sebazzz there seems to be a typo in your example:
I think you need to change:
to
|
So Gitea won't be able to pass the committer name as a variable as that's in the commits themselves - you'd need to examine the commit and then interrogate Gitea over the API to do it. I am aware of how to go about adding this to Gitea's protected branch stuff but I've not had time. If you're willing and understand what I've written in #8584 this could be a good PR. |
Ah, I'd forgotten what this issue was asking for. Yeah we don't put the full name or email address in the environment because we don't use it - however you can easily get that from the Gitea API with a sufficiently powerful token (if you need to override hide email address) at Yeah it's a little slow to have to send an API request but it's not overly long. |
Not entirely sure, but I think "Verified Committer" on comparison page in docs should have a tick for Gitea? https://docs.gitea.io/en-us/comparison/#code-management |
I'm gonna make it "/" because if we're gonna say we do this I think we will need to do it properly. |
Git and distributed version control have many benefits out of the box, but controlling access and workflows isn’t one of them. For example, without a Git management tool, a developer can push commits that others have written to the central repository.
This creates problems for organizations with strict security and compliance requirements.
It is necessary to add a new committer verification hook, which enforces that only the author of a commit can push those changes back to Gogs Server. We can sleep easy knowing that only authorized code changes can make it to your repositories.
BitBucket has added this feature.
https://www.atlassian.com/blog/bitbucket/enterprise-devops-bitbucket-server-5-bamboo-6
And GitLab adds too.
https://gitlab.com/gitlab-org/gitlab-ee/issues/1802
The text was updated successfully, but these errors were encountered: