Naar de hoofdinhoud

Pushes en de committerregel

De author en committer van een commit zijn tekst die degene die commit zelf in zijn git-config typt: iedereen kan daar ieders naam en adres neerzetten. Wat fremforge zeker weet, is wie er pushte: het account waarvan het HTTPS-token, het OAuth-token of de SSH-sleutel de verbinding opende. Daarop bouwen twee dingen voort:

  • Toeschrijving aan de pusher. Elke push naar een repository in je organisatie wordt met dat account vastgelegd, ongeacht hoe de regel hieronder is ingesteld.
  • De committerregel. Die kan eisen dat elke commit die nieuw is in de repository een committer-adres heeft dat toebehoort aan degene die hem pusht.

Het overzicht van wie er pushte

fremforge legt elke ref-update in een push vast:

  • de pusher: het account dat zich authenticeerde;
  • hoe die zich authenticeerde: HTTPS (een persoonlijk toegangstoken of het OAuth-token van Git Credential Manager), een SSH-sleutel, een deploy key met zijn sleutel-id, of een token van een Actions-job;
  • de ref, en de oude en nieuwe commit ervan;
  • in een repository waarvan de committerregel op waarschuwen of blokkeren staat, de commits die nieuw waren in de repository;
  • de beslissing van de committerregel.

Het overzicht komt uit de eigen authenticatie van Forgejo, nooit uit iets wat de client meestuurt. Commits die fremforge zelf maakt, worden niet vastgelegd: merges, de merge queue en bewerkingen in de webeditor.

Je vindt het in de console onder Beveiliging › Push-bescherming › Pushes en de committerregel. De pagina toont recente pushes en een zoekfunctie die de push vindt die een bepaalde commit binnenbracht. Met de 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>"

De zoekfunctie vindt een commit onder de eerste 500 nieuwe commits van elke ref-update, in repository’s waarvan de committerregel op waarschuwen of blokkeren stond toen hij werd gepusht. Staat de regel uit, dan wordt een push vastgelegd met zijn refs en pusher maar zonder zijn commits, zodat het vastleggen een push nooit vertraagt. Elke push staat ook in het auditlog als git.push, met het sleutel-id bij een push met een deploy key.

De committerregel

De regel is Committer moet overeenkomen met pusher. Elke commit die nieuw is in de repository moet een committer-adres hebben dat een van de volgende is:

  • een van de bevestigde e-mailadressen van de pusher op frem.sh (Instellingen › Account). Een adres dat is toegevoegd maar nooit bevestigd, telt niet;
  • of het no-reply-adres van de pusher, <login>@noreply.frem.sh, dat alleen dat account kan gebruiken.
ModusWat er gebeurt
Uit (de standaard voor een organisatie aangemaakt vóór 2026-10-27)Pushes worden vastgelegd; er wordt niets gecontroleerd.
Waarschuwen (de standaard voor een organisatie aangemaakt op of na 2026-10-27)De push wordt geaccepteerd, en de pusher hoort welke commits niet overeenkomen.
BlokkerenDe push wordt geweigerd tot elke nieuwe commit overeenkomt.

Een organisatie die op of na 2026-10-27 is aangemaakt, begint in Waarschuwen: er wordt nooit een push geweigerd, en een pusher wiens commit een adres draagt dat hij niet heeft bevestigd, krijgt dat te horen. Een eigenaar kan de regel op elk moment uitzetten of op Blokkeren zetten. Bij Waarschuwen wacht een push op de controle: gemeten op 2026-10-27 is dat in de mediaan ongeveer 90 ms.

Alleen commits die nieuw zijn in de repository worden gecontroleerd. Een commit die al op een andere branch staat, is gecontroleerd toen hij voor het eerst binnenkwam. Als je main in je branch samenvoegt, hoef je dus niet in te staan voor de commits van anderen.

Een geweigerde push noemt de commits en adressen:

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.

Wat niet wordt gecontroleerd

  • Pushes met het token van een Actions-job. Een workflow pusht als de job, niet als een persoon.
  • Platformbots. Dat zijn de accounts die fremforge zelf draait, zoals de bots voor beveiligingsfixes en Renovate.
  • Uitgezonderde gebruikers die je bij de regel opgeeft, bijvoorbeeld een serviceaccount dat als zichzelf pusht.
  • Deploy sleutels. Een deploy key heeft geen persoon en geen bevestigd adres. Pushes ermee worden vastgelegd met het sleutel-id en niet gecontroleerd, tenzij je Pushes met een deploy key weigeren in blokkeermodus kiest; dan worden ze geweigerd zolang de regel in blokkeermodus staat.
  • Commits die fremforge maakt: merges, de merge queue en bewerkingen op het web.

Als de controle niet kan draaien

Als fremforge de controle niet kan uitvoeren (bijvoorbeeld omdat de dienst die hem beantwoordt niet binnen 2 seconden reageert), wordt de push geaccepteerd, in elke modus. Hij wordt vastgelegd als Niet gecontroleerd, en in blokkeermodus worden de operators van fremforge gealarmeerd. Elke push weigeren zodra een controle niet beschikbaar is, zou het werk van je teams stilleggen. Daarom faalt de regel open en is de misser zichtbaar: in het pushoverzicht en voor de operators. Zoek in de pushgegevens naar de beslissing Niet gecontroleerd.

Instellen

In de console stel je de regel van de organisatie in onder Beveiliging › Push-bescherming › Pushes en de committerregel. Een repository kan een eigen regel hebben, die voor die repository de regel van de organisatie vervangt. Die stel je in met de 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"

Voor het wijzigen van een regel is de scope policy:write nodig, en elke wijziging staat in het auditlog als push-protection.committer-rule.updated. Een regel die je inschakelt of wijzigt, geldt binnen 60 seconden voor pushes.

Voordat je blokkeren inschakelt

  • Laat de regel een tijd op Waarschuwen staan en kijk in het pushoverzicht naar rijen met Gewaarschuwd. Die laten zien wie commit met een adres dat hij niet heeft bevestigd.
  • Vraag mensen het adres te bevestigen dat hun git-config gebruikt, of user.email op hun no-reply-adres te zetten.
  • Geschiedenis importeren (een bestaand project pushen met commits van anderen) mislukt in blokkeermodus, omdat die commits nieuw zijn in de repository en door anderen zijn gemaakt. Importeer in waarschuwmodus, of zonder de importeur uit voor de import. Meer dan 5000 nieuwe commits in één push worden in blokkeermodus geweigerd, omdat de regel er hoogstens 5000 controleert; push de geschiedenis dan in delen.

Vergeleken met GitHub

GitHub heeft dezelfde regel, “Committer must match pusher”, in een beperkte preview voor GitHub Enterprise (2026-10-12). GitHub legt de pusher per commit vast. fremforge legt de pusher per ref-update vast, met de nieuwe commits waar de regel aan staat, en heeft een zoekfunctie op commit.