Sécurité : ouvrir les PR du bot depuis un fork de code-bot #20

New issue

Open

opened 2026-10-14 02:39:17 +02:00 by mathieu · 0 comments

mathieu commented

2026-10-14 02:39:17 +02:00

Owner

Constat (lanes#13)

La PR qu'ouvre la lane code a sa branche dans le dépôt : Forgejo donne à la CI de cette PR un jeton automatique en écriture. Mesuré sur essai-actions le 2026-10-14 (run 460, essai-jeton.yml) : ce jeton écrit des références hors branches (refs/…, qu'aucune protection ne couvre) et lance un workflow_dispatch (HTTP 204), donc un workflow qui tourne avec les secrets du dépôt. Forgejo v16 n'a ni clé permissions ni réglage d'instance pour le restreindre.

Atténuations en service (879a8a9) : main protégée sur les dépôts équipés ; CI des dépôts équipés qui exécutent le code de la PR sous node, environnement vidé (env -i … runuser -u node -- env -i …), sans le jeton. Elles reposent sur la discipline de chaque CI : un nouveau workflow en root rouvre le trou.

Parade structurelle

Une PR de fork reçoit un jeton en lecture seule, pour git comme pour l'API, et pas les secrets du dépôt, pull_request_target compris. Faire pousser code (et fix) dans un fork appartenant à code-bot, et ouvrir la PR depuis ce fork.

À trancher, à éprouver sur essai-actions

Un fork par dépôt équipé, créé par installer.py ou à la main ; synchronisation de la branche par défaut du fork.
code et fix poussent avec LANE_BOT_TOKEN vers le fork ; la condition « même dépôt » de fix est à revoir (aujourd'hui elle refuse justement les PR de fork).
review et fix lancés sur une PR de fork : vérifier qu'ils publient encore (revue, commentaire, push sur la branche du fork) — le jeton du job y est en lecture, publier avec LANE_BOT_TOKEN.
Motif ci de fix et CI de la tête vue par review : les runs d'une PR de fork se lisent-ils pareil par l'API ?
Faire confiance une fois aux workflows du fork si l'instance exige une approbation pour les PR de fork.

Critères d'acceptation

Sur essai-actions, une PR ouverte par code vient d'un fork de code-bot, et sa CI a un jeton qui ne pousse pas et ne lance pas de dispatch (sondes de essai-jeton.yml).
review et fix fonctionnent sur cette PR.
CONTRAT.md, section « CI aval », passe de « reste à faire » à la description du fonctionnement ; installer.py documente la création du fork.

Refs #13

## Constat (lanes#13) La PR qu'ouvre la lane `code` a sa branche dans le dépôt : Forgejo donne à la CI de cette PR un jeton automatique **en écriture**. Mesuré sur essai-actions le 2026-10-14 (run 460, `essai-jeton.yml`) : ce jeton écrit des références hors branches (`refs/…`, qu'aucune protection ne couvre) et lance un `workflow_dispatch` (HTTP 204), donc un workflow qui tourne avec les secrets du dépôt. Forgejo v16 n'a ni clé `permissions` ni réglage d'instance pour le restreindre. Atténuations en service (879a8a9) : `main` protégée sur les dépôts équipés ; CI des dépôts équipés qui exécutent le code de la PR sous `node`, environnement vidé (`env -i … runuser -u node -- env -i …`), sans le jeton. Elles reposent sur la discipline de chaque CI : un nouveau workflow en root rouvre le trou. ## Parade structurelle Une PR **de fork** reçoit un jeton en lecture seule, pour git comme pour l'API, et pas les secrets du dépôt, `pull_request_target` compris. Faire pousser `code` (et `fix`) dans un fork appartenant à `code-bot`, et ouvrir la PR depuis ce fork. ## À trancher, à éprouver sur essai-actions - Un fork par dépôt équipé, créé par `installer.py` ou à la main ; synchronisation de la branche par défaut du fork. - `code` et `fix` poussent avec `LANE_BOT_TOKEN` vers le fork ; la condition « même dépôt » de `fix` est à revoir (aujourd'hui elle refuse justement les PR de fork). - `review` et `fix` lancés sur une PR de fork : vérifier qu'ils publient encore (revue, commentaire, push sur la branche du fork) — le jeton du job y est en lecture, publier avec `LANE_BOT_TOKEN`. - Motif `ci` de `fix` et CI de la tête vue par `review` : les runs d'une PR de fork se lisent-ils pareil par l'API ? - Faire confiance une fois aux workflows du fork si l'instance exige une approbation pour les PR de fork. ## Critères d'acceptation - [ ] Sur essai-actions, une PR ouverte par `code` vient d'un fork de `code-bot`, et sa CI a un jeton qui ne pousse pas et ne lance pas de dispatch (sondes de `essai-jeton.yml`). - [ ] `review` et `fix` fonctionnent sur cette PR. - [ ] CONTRAT.md, section « CI aval », passe de « reste à faire » à la description du fonctionnement ; `installer.py` documente la création du fork. Refs #13

mathieu referenced this issue

2026-10-14 02:39:54 +02:00

Évasion par la CI aval : la PR de la lane code fait exécuter le code de l'agent avec le jeton du job #13

mathieu added the

labels

2026-10-19 23:19:57 +02:00