Feature Request: add "forward only" option for GitRepository with signed commits

[bb-Ricardo]

I'm wondering if it is possible to implement a GitRepository option to only accept new signed commits which are a child of the current validated signed commit.

Current situation:

At the moment it is possible to reset the GIT history to an older singed commit by force pushing and the source controller accepts the commit. This permits user, which have write permission to the GIT repository to change the deployment to an older state even though their public key is not in the list of permitted signers.

example GIT log:

commit 5b468b41996fcb4146bb8fe9e88aa6735c799fc9
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:53:01 2026 +0100

    second signed commit

commit f99de69ed074fd3b59570786d515ed4ba56aef12
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:52:15 2026 +0100

    first signed commit

commit 721a520671afc30070c0767baff4f44a4fe72fab
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:51:42 2026 +0100

    initial commit

If the source controller has currently checked out and verified commit 5b468b41996fcb4146bb8fe9e88aa6735c799fc9 it is possible for user a user with write access to the repo but without the users key in the list of trusted keys to do following:

git reset --hard f99de69ed074fd3b59570786d515ed4ba56aef12
git push -f

The source-controller would checkout and verify commit f99de69ed074fd3b59570786d515ed4ba56aef12 even though the change was performed by a user that should not be permitted to perform changes within this GitRepository resource.

Technically: if the same repo would contain a kustomization with the secret of permitted signers. A user with write access to the repo and who was previously in the list of permitted singers could revert to a version where the user was in the list. The secret would be revert to the old state and the user could push a complete different configuration with a now valid signed commit.

Possible solution:

Adding a config option which permit for "forward-only" changes. It should not be possible to reset the history to an older GIT commit id. Only signed revert commits or regular commits which are child of the current parent are accepted.

example GIT log:

commit 683408a1ae2425940ea5cc7b3d9120fdf1dd274f
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:54:20 2026 +0100

    another signed commit

commit dfd2c8d0ab2ff2ebc27601fd0bc7beb11c392d2b
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:53:49 2026 +0100

    an example unsigned commit

commit 5b468b41996fcb4146bb8fe9e88aa6735c799fc9 (HEAD -> main)
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:53:01 2026 +0100

    second signed commit

commit f99de69ed074fd3b59570786d515ed4ba56aef12
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:52:15 2026 +0100

    first signed commit

commit 721a520671afc30070c0767baff4f44a4fe72fab
Author: Example User <user@axample.com>
Date:   Mon Mar 23 22:51:42 2026 +0100

    initial commit

Situation:

• forward-only is enabled
• currently checked out commit id is 5b468b41996fcb4146bb8fe9e88aa6735c799fc9

Now the source-controller would:

• not accept a reset of HEAD to commit f99de69ed074fd3b59570786d515ed4ba56aef12 as this commit would not be a child of the current checked out commit.
• not accept commit dfd2c8d0ab2ff2ebc27601fd0bc7beb11c392d2b as it's an unsigned or invalid signed commit
• would accept commit 683408a1ae2425940ea5cc7b3d9120fdf1dd274f as it is a child commit of 5b468b41996fcb4146bb8fe9e88aa6735c799fc9 and has a valid signature.

This permits only user which are in the list of permitted signers to push commits which are accepted by the source-controller.

This would require to backtrack the git history to a matching current git commit id if new commits are pushed. Not sure how much performance or memory this would cost, but this would improve supply chain security quite a lot, from my point of view.

[matheuscscp]

I think go-git probably would have some operation to check if the new commit comes from the old one... I'd not mind a PR adding a boolean field for this

[bb-Ricardo]

great, then I will look into implementing this option.