Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,010 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
git, go
Área
backend, security

Línea de trabajo

No se nombran archivos de implementación ni pruebas. Empieza rastreando la reconciliación de GitRepository y el flujo actual de checkout del commit y validación de firmas de source-controller. Define cómo se realiza el seguimiento del commit validado almacenado, cómo se comprueba la ascendencia después de un force push y añade cobertura para commits hijos aceptados, resets rechazados y firmas no válidas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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 <[email protected]>
Date:   Mon Mar 23 22:53:01 2026 +0100

    second signed commit

commit f99de69ed074fd3b59570786d515ed4ba56aef12
Author: Example User <[email protected]>
Date:   Mon Mar 23 22:52:15 2026 +0100

    first signed commit

commit 721a520671afc30070c0767baff4f44a4fe72fab
Author: Example User <[email protected]>
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 <[email protected]>
Date:   Mon Mar 23 22:54:20 2026 +0100

    another signed commit

commit dfd2c8d0ab2ff2ebc27601fd0bc7beb11c392d2b
Author: Example User <[email protected]>
Date:   Mon Mar 23 22:53:49 2026 +0100

    an example unsigned commit

commit 5b468b41996fcb4146bb8fe9e88aa6735c799fc9 (HEAD -> main)
Author: Example User <[email protected]>
Date:   Mon Mar 23 22:53:01 2026 +0100

    second signed commit

commit f99de69ed074fd3b59570786d515ed4ba56aef12
Author: Example User <[email protected]>
Date:   Mon Mar 23 22:52:15 2026 +0100

    first signed commit

commit 721a520671afc30070c0767baff4f44a4fe72fab
Author: Example User <[email protected]>
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.

Lenguaje dominante
Go
Estrellas
283
Forks
258
Merge medio
1 d 17 h
PR fusionados (30 d)
15

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de fluxcd/source-controller

Todos los issues de fluxcd/source-controller

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.