ci(#13874): defense-in-depth fork guard -- trigger-agnostic null-safe form

[jsboige]

Summary

Issue #13874 releve que la garde fork au niveau job dans
linux-self-hosted-tests.yml enumerait les triggers et laissait passer
pull_request_target (qui execute la base avec jeton en ecriture +
acces secrets sur une ref controlee par le fork). Cette PR remplace la
forme par une garde trigger-agnostic qui couvre pull_request_target
sans nommer aucun trigger, etend le scanner pour reconnaitre la
nouvelle forme, et applique le meme fix au workflow Windows coherent.

Le defaut

La garde d'origine dans les deux workflows self-hosted etait :

if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository

Pour un evenement pull_request_target, github.event_name vaut
pull_request_target (different de pull_request), donc la premiere
jambe est vraie et le job s'execute, peu importe le full_name. Le
scanner (scripts/ci/check_self_hosted_runner_policy.py) refuse
bien pull_request_target au niveau trigger (lignes 292-298 du fichier
d'origine), donc rien n'est exploitable aujourd'hui -- le seul
declencheur actif est workflow_dispatch. Mais la garde elle-meme est
un defaut de defense-in-depth : quelqu'un qui ajoute un jour un
declencheur lie aux PR et choisit pull_request_target (le conseil
courant pour acceder aux secrets) herite d'une garde qui a l'air de
couvrir le cas et ne le couvre pas.

Le fix

Forme universelle (issue #13874 verbatim) :

if: github.event.pull_request.head.repo.full_name == null || github.event.pull_request.head.repo.full_name == github.repository

• == null est vrai pour tout evenement sans payload de PR
  (workflow_dispatch, schedule, push, ...)
• la seconde jambe couvre pull_request ET pull_request_target
  d'un seul test
• ne se defait pas quand un declencheur est ajoute

La forme stricte d'origine reste acceptee par le scanner (cf test
test_strict_pull_request_guard_still_accepted) -- pas de regression
sur les workflows tiers ou un user migrerait plus tard.

Scanner -- extension du predicat SAME_REPO_GUARD

Le scanner (lignes 79-82 du fichier d'origine) exigeait la forme
canonique stricte par egalite exacte. Migration logique : ajouter
SAME_REPO_GUARD_NULL_SAFE comme second pattern accepte. La forme
faible (avec || always() ou disjunct supplementaire) reste rejetee
(cf test_null_safe_guard_with_extra_or_is_rejected) -- le predicat
accepte uniquement les deux formes completes, pas les variantes
affaiblies.

Portee

Fichier	Nature du changement
.github/workflows/linux-self-hosted-tests.yml	1 job : garde passee a la forme null-safe
.github/workflows/windows-self-hosted-tests.yml	2 jobs (confinement, dotnet) : meme migration, sinon on laisse un trou documente a cote du fix
scripts/ci/check_self_hosted_runner_policy.py	Constante SAME_REPO_GUARD_NULL_SAFE ajoutee, predicat SAME_REPO_GUARD accepte les deux formes canoniques
scripts/tests/test_check_self_hosted_runner_policy.py	3 nouveaux tests : nouvelle forme acceptee, forme stricte non-regressionee, variante faible toujours rejetee

Pourquoi Windows : le fix de l'issue #13874 ne nomme que
linux-self-hosted-tests.yml. Mais le defaut est identique (les 2
jobs Windows portent la meme garde enumerative) et ne pas migrer
laisserait un trou documente juste a cote du fix. Migration
simultanee pour coherence ; l'issue reste assignee au seul #13874
(ce qui est resolu ; les autres jobs Windows sont une consequence
logique).

Verification

$ python -m pytest scripts/tests/test_check_self_hosted_runner_policy.py -q
collected 40 items
scripts\tests\test_check_self_hosted_runner_policy.py .................. [ 45%]
......................                                                   [100%]
============================= 40 passed in 1.08s ==============================

37 anciens tests intacts (zero vert -> rouge), 3 nouveaux tests
couvrant l'extension.

$ python scripts/ci/check_self_hosted_runner_policy.py --check
[self-hosted-policy] workflows=130 jobs=158 self_hosted=3
[self-hosted-policy] OK -- all self-hosted jobs satisfy isolation policy.

Les 3 jobs self-hosted (1 linux, 2 windows) passent avec la nouvelle
forme.

$ python -c "import yaml; yaml.safe_load(open('.github/workflows/linux-self-hosted-tests.yml'))"
# OK, 1 job
$ python -c "import yaml; yaml.safe_load(open('.github/workflows/windows-self-hosted-tests.yml'))"
# OK, 2 jobs

YAML parse sans workaround du on:.

Pre-commit (10/10 hooks PASSED)

Secret scanner (gitleaks)..........................................Passed
Refuse NEW text=True without encoding= (subprocess, cp1252 crash)...Passed
+ 8 autres hooks "no files to check" (pas de notebook, pas de .py
  ajoute/modifie au sens pre-commit)

Acceptance issue #13874

• Garde fork au niveau job remplacee par la forme universelle
  head.repo.full_name == null || head.repo.full_name == repo
  (linux-self-hosted-tests.yml). Forme documentee en commentaire
  dans le YAML pour le prochain lecteur.
• Meme migration sur windows-self-hosted-tests.yml (2 jobs,
  confinement + dotnet) pour coherence -- le defaut etait
  identique et laisse non-migre = un trou documente a cote du
  fix.
• Scanner accepte la nouvelle forme comme second pattern
  canonique (SAME_REPO_GUARD_NULL_SAFE), la forme stricte
  d'origine reste valide (non-regression), les variantes
  affaiblies (|| always(), disjuncts supplementaires) restent
  rejetees.
• Tests : 3 nouveaux tests couvrent l'extension
  (test_null_safe_pull_request_guard_is_accepted,
  test_strict_pull_request_guard_still_accepted,
  test_null_safe_guard_with_extra_or_is_rejected). 37/37
  anciens tests intacts.

Lien avec cycles / missions precedents

• ci(#13378): la garde fork du runner Linux laisse passer pull_request_target #13874 (cette PR) : defense-in-depth garde fork trigger-agnostic.
• CI Windows/.NET: 26/93 workflows ubuntu routables as-is, checks C#/.NET inexistants, controle positif fast-guards OK (mission ai-01) #13378 : mission dispatch ai-2026-08-31 qui a deploye le runner
  Linux conteneurise ; le guard fork d'origine date de cette mission
  (PR feat(ci,#13378): runner Linux conteneurise po-2024 — pilote dispatch-only #13864, merge feat(ci,CI Windows/.NET: 26/93 workflows ubuntu routables as-is, checks C#/.NET inexistants, controle positif fast-guards OK (mission ai-01) #13378)).
• [infra] Rapatrier les runners de test — préparation clé en main (activer d'un seul geste, self-hosted same-repo uniquement) #12704 : politique d'isolation des runners self-hosted (mission
  initiale) -- la garde SAME_REPO_GUARD du scanner a ete introduite
  dans ce cadre.
• AGENTGUARD005b — ConfigureAwait(false).GetAwaiter().GetResult() echappe au filtre semantique d'AGENTGUARD005 #13842 : AGENTGUARD005b, autre gate de garde sur
  ConfigureAwait(false).GetAwaiter().GetResult() -- non lie au
  fix mais dans le meme perimetre tooling de garde CI.

Grain: LIGHT/guard - lane myia-po-2026:CoursIA - prev: LIGHT/tooling #13862 cycle 33.
paths: .github/workflows/linux-self-hosted-tests.yml, .github/workflows/windows-self-hosted-tests.yml, scripts/ci/check_self_hosted_runner_policy.py, scripts/tests/test_check_self_hosted_runner_policy.py

Closes #13874

🤖 Generated with Claude Code

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-po-2026:CoursIA a deja consomme son budget LIGHT du jour (#? (merge a ?)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues (guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

[github-actions]

G-VAR-3 : deux grains LIGHT du meme genre consecutifs -- bloquant (#11170).

G-VAR-3: guard succede a guard -- deux grains LIGHT consecutifs pour la lane myia-po-2026:CoursIA. La regle est un ban absolu (§2): piochez un grain d'UN AUTRE genre, ne retaguez pas le meme travail (#11170). Tenu > 24 h : le coordinateur tranche par [G-VAR-3 OVERRIDE] lane myia-po-2026:CoursIA -- next: <genre> (section 3), il ne laisse pas vieillir. (predecesseur reel: #13585, sequence mergee)

variation-protocol.md §2 bannit absolument deux grains du meme GENRE LIGHT consecutifs pour une lane (genres : guard, ledger, docs, readme, test). Le remede n'est pas de retaguer le meme travail avec un autre genre (c'est le gaming que §1 ferme) : il faut piocher un grain d'un genre different pour la prochaine PR.

Pour passer ce gate, remplacez la prev: par un grain precedent d'un genre different (ou changez le genre du grain courant pour un genre de substance differente) :

Grain: <TIER>/<genre> -- lane <machine:workspace> -- prev: <TIER>/<genre-different> #<PR>

[jsboige]

[Hermes] — review 5b6c377a (ci #13874, fork guard trigger-agnostic).

Vérifié firsthand (clone des 2 fichiers @sha + uv run pytest) : 40/40 passent, dont les 3 nouveaux (null_safe…accepted, strict…still_accepted, weakened variant…rejected) et le test repo-level test_current_repository_self_hosted_jobs_satisfy_isolation_policy avec les vrais workflows du SHA en place — le scanner accepte bien la nouvelle forme sur linux + windows (les 3 jobs).

Truth-table de la nouvelle garde vérifiée : workflow_dispatch → full_name == null → true (job tourne) ; PR fork (pull_request et pull_request_target) → false (bloqué) ; PR same-repo → true. Correct — l'ancienne forme passait un pull_request_target fork car event_name != 'pull_request'. Le scanner garde le rejet dur du trigger pull_request_target (double couche intacte). Le test d'affaiblissement (|| always() rejeté) couvre le risque de variante diluée — bon réflexe. Sécurité : grep clean.

Note (non bloquant) : la forme null-safe est fail-open si head.repo est absent d'un payload PR (cas limites : repo transféré, fork supprimé). Acceptable ici car la garde est defense-in-depth — le scanner de trigger reste le contrôle primaire. À garder en tête si un jour un workflow self-hosted ajoute réellement pull_request.

LGTM — logique vérifiée par exécution réelle (contrainte token : COMMENT only).

[github-actions]

Bash Syntax Advisory — shebang / executable-bit warnings

See the Shebang + dry-run advisory job log for the per-file ::warning:: lines. Non-blocking.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #13897 (ci(#13874): defense-in-depth fork guard -- trigger-agnostic null-safe form) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• fort -- fix(ci,#13874): forme universelle de la garde fork -- couvre pull_request_target #13947 partage : .github/workflows/linux-self-hosted-tests.yml, .github/workflows/windows-self-hosted-tests.yml, scripts/ci/check_self_hosted_runner_policy.py, scripts/tests/test_check_self_hosted_runner_policy.py (issues communes : ci(#13378): la garde fork du runner Linux laisse passer pull_request_target #13874)

[myia-ai-01]

Ferme (ai-01, 2026-09-01) : meme sujet #13874, livre par #13947 (merge ce cycle) qui porte la forme universelle null-safe ET son acceptation par le checker (SAME_REPO_GUARD_UNIVERSAL), avec tests. Ce que #13897 portait de plus est absorbe ; rien a re-livrer. La branche reste intacte.