Push et règle du committer
L’auteur et le committer d’un commit sont du texte que la personne qui committe saisit dans sa configuration git : n’importe qui peut y écrire le nom et l’adresse de n’importe qui. Ce que fremforge sait avec certitude, c’est qui a fait le push : le compte dont le jeton HTTPS, le jeton OAuth ou la clé SSH a ouvert la connexion. Deux fonctionnalités reposent sur ce fait :
- L’attribution du push. Chaque push vers un dépôt de votre organisation est enregistré avec ce compte, quel que soit le réglage de la règle ci-dessous.
- La règle du committer. Elle peut exiger que chaque commit nouveau dans le dépôt ait une adresse de committer appartenant à la personne qui le pousse.
L’enregistrement de l’auteur du push
fremforge enregistre chaque mise à jour de ref d’un push :
- l’auteur du push : le compte qui s’est authentifié ;
- comment il s’est authentifié : HTTPS (un jeton d’accès personnel ou le jeton OAuth de Git Credential Manager), une clé SSH, une clé de déploiement avec son identifiant, ou un jeton de job Actions ;
- la ref, ainsi que son ancien et son nouveau commit ;
- dans un dépôt dont la règle du committer est en mode avertir ou bloquer, les commits nouveaux dans le dépôt ;
- la décision de la règle du committer.
L’enregistrement provient de l’authentification propre de Forgejo, jamais de ce qu’envoie le client. Les commits que fremforge crée lui-même ne sont pas enregistrés : fusions, file de fusion et modifications dans l’éditeur web.
Vous le trouverez dans la console sous Sécurité › Protection des push › Push et règle du committer. La page affiche les push récents et une recherche qui retrouve le push ayant apporté un commit donné. Avec l’API :
# Recent pushes, or those to one repository
curl -H "Authorization: Bearer $TOKEN" \
"https://frem.sh/_app/api/v1/orgs/acme/push-protection/push-records?repository=web"
# Which push brought this commit?
curl -H "Authorization: Bearer $TOKEN" \
"https://frem.sh/_app/api/v1/orgs/acme/push-protection/push-records?commit=<full commit id>"La recherche retrouve un commit parmi les 500 premiers nouveaux commits de chaque mise à jour de ref, dans les dépôts dont la règle du committer était en mode avertir ou bloquer au moment du push. Lorsque la règle est désactivée, un push est enregistré avec ses refs et son auteur, mais sans ses commits, afin que l’enregistrement ne ralentisse jamais un push. Chaque push figure également dans le journal d’audit sous git.push, avec l’identifiant de la clé de déploiement pour un push par clé de déploiement.
La règle du committer
La règle est le committer doit correspondre à l’auteur du push. Chaque commit nouveau dans le dépôt doit avoir une adresse de committer qui est :
- soit l’une des adresses e-mail confirmées de l’auteur du push sur frem.sh (Paramètres utilisateur › Compte). Une adresse ajoutée mais jamais confirmée ne compte pas ;
- soit l’adresse no-reply de l’auteur du push,
<login>@noreply.frem.sh, que seul ce compte peut utiliser.
| Mode | Ce qui se passe |
|---|---|
| Désactivée (par défaut pour une organisation créée avant le 2026-10-27) | Les push sont enregistrés ; rien n’est vérifié. |
| Avertir (par défaut pour une organisation créée le 2026-10-27 ou après) | Le push est accepté, et l’auteur du push est informé des commits qui ne correspondent pas. |
| Bloquer | Le push est refusé tant que chaque nouveau commit ne correspond pas. |
Une organisation créée le 2026-10-27 ou après démarre en mode Avertir : aucun push n’est jamais refusé, et un auteur de push dont le commit porte une adresse qu’il n’a pas confirmée en est informé. Un propriétaire peut désactiver la règle, ou choisir Bloquer, à tout moment. Le mode avertir fait attendre le push le temps de la vérification : environ 90 ms en médiane, mesuré le 2026-10-27.
Seuls les commits nouveaux dans le dépôt sont vérifiés. Un commit déjà présent sur une autre branche a été vérifié à sa première arrivée ; fusionner main dans votre branche ne vous rend donc pas responsable des commits des autres.
Un push refusé indique les commits et les adresses :
remote: fremforge: push refused: the committer of 1 new commit is not one of your verified email addresses.
remote: 3f2a9c1b8e7d someone@example.com
remote: Set user.email to one of them, rewrite these commits (git rebase -i, or git commit --amend --reset-author), and push again.Ce qui n’est pas vérifié
- Les push effectués avec un jeton de job Actions. Un workflow pousse en tant que job, et non en tant que personne.
- Les bots de la plateforme. Ce sont les comptes que fremforge exploite lui-même, comme les bots de correctifs de sécurité et de Renovate.
- Les utilisateurs exemptés que vous listez dans la règle, par exemple un compte de service qui pousse en son propre nom.
- Les clés de déploiement. Une clé de déploiement n’a ni personne ni adresse vérifiée. Ses push sont enregistrés avec l’identifiant de la clé et ne sont pas vérifiés, sauf si vous choisissez Refuser les push par clé de déploiement en mode blocage, qui les refuse tant que la règle est en mode bloquer.
- Les commits que crée fremforge : fusions, file de fusion et modifications web.
Si la vérification ne peut pas s’exécuter
Si fremforge ne peut pas exécuter la vérification (par exemple, le service qui y répond ne répond pas dans les 2 secondes), le push est accepté, quel que soit le mode. Il est enregistré comme Non vérifié et, en mode bloquer, les opérateurs de fremforge reçoivent une alerte. Refuser tous les push chaque fois qu’une vérification est indisponible arrêterait le travail de vos équipes : la règle échoue donc en mode ouvert, et l’échec reste visible, dans le journal des push et pour les opérateurs. Cherchez la décision Non vérifié dans les enregistrements de push.
Configuration
Dans la console, Sécurité › Protection des push › Push et règle du committer définit la règle de l’organisation. Un dépôt peut avoir sa propre règle, qui remplace celle de l’organisation pour ce dépôt. Définissez-la avec l’API :
# The organisation's rule
curl -X PUT -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
-d '{"mode": "block", "refuse_deploy_keys": false, "exempt_users": ["acme-release-bot"]}' \
"https://frem.sh/_app/api/v1/orgs/acme/push-protection/committer-rule"
# One repository's own rule, and back to the organisation's
curl -X PUT -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
-d '{"mode": "warn"}' "https://frem.sh/_app/api/v1/orgs/acme/push-protection/committer-rule/repos/legacy-import"
curl -X DELETE -H "Authorization: Bearer $TOKEN" \
"https://frem.sh/_app/api/v1/orgs/acme/push-protection/committer-rule/repos/legacy-import"Modifier une règle nécessite la portée policy:write, et chaque modification figure dans le journal d’audit sous push-protection.committer-rule.updated. Une règle que vous activez ou modifiez s’applique aux push sous 60 secondes.
Avant d’activer le blocage
- Utilisez le mode avertir pendant un certain temps, et lisez les lignes Averti du journal des push. Elles montrent qui committe avec une adresse non confirmée.
- Demandez à chacun de confirmer l’adresse qu’utilise sa configuration git, ou de définir
user.emailsur son adresse no-reply. - L’import d’un historique (le push d’un projet existant contenant les commits d’autres personnes) échoue en mode bloquer, car ces commits sont nouveaux dans le dépôt et ont été créés par d’autres. Importez en mode avertir, ou exemptez la personne qui importe le temps de l’import. Un push de plus de 5000 nouveaux commits est refusé en mode bloquer, car la règle en vérifie au plus 5000 ; poussez l’historique en plusieurs fois.
Comparaison avec GitHub
GitHub propose la même règle, « Committer must match pusher », en préversion limitée pour GitHub Enterprise (2026-10-12). Il enregistre l’auteur du push par commit. fremforge enregistre l’auteur du push par mise à jour de ref, avec les nouveaux commits lorsque la règle est active, et propose une recherche par commit.