GitHub testera le lundi 9 novembre un blocage temporaire de l’événement pull_request_target dans les dépôts publics concernés. Un second essai est prévu le 16 novembre, avant l’application permanente de la règle par défaut le 2 décembre. Pour les équipes qui utilisent cet événement dans leurs automatisations, la première échéance arrive avant le changement définitif. Elles peuvent déjà repérer quels traitements seraient bloqués et vérifier pourquoi ils utilisent ce déclencheur.
Deux fenêtres de test avant décembre
D’après l’annonce de GitHub, les fenêtres des 9 et 16 novembre courent de 16 h à 18 h UTC, soit de 17 h à 19 h à Paris. Pendant ces périodes, la protection par défaut s’appliquera dans les dépôts publics concernés. Une exécution bloquée apparaîtra en échec avec une annotation et le workflow ne tournera pas. Après chaque essai, la règle repassera en mode d’évaluation. Les workflows concernés pourront alors fonctionner à nouveau avec un avertissement.
Le calendrier laisse du temps pour distinguer un échec provoqué par cette protection d’une erreur du code. Si une demande externe arrive pendant la fenêtre et qu’une vérification ne démarre pas, consultez d’abord l’annotation. Gardez la référence du workflow, l’heure et la demande concernée. Cela facilite le diagnostic lorsque le même événement se reproduit après la mise en application permanente.
Pourquoi l’événement mérite une attention particulière
L’événement pull_request_target utilise le contexte du dépôt de base. Un workflow exécuté dans ce contexte peut accéder à des permissions et à des secrets dont un contributeur externe ne dispose pas directement. Le risque apparaît lorsque le workflow récupère puis exécute du code fourni par un fork, ou lorsqu’il laisse des données d’une demande externe devenir des commandes exécutables. L’automatisation et le code qu’elle traite doivent être examinés ensemble.
Un dépôt peut utiliser cet événement pour classer une demande, appliquer une étiquette ou lancer un autre traitement. Ces usages ne manipulent pas tous les mêmes données. Suivez l’entrée du workflow jusqu’aux commandes qu’il lance. Notre article sur le périmètre des protections GitHub souligne l’intérêt de vérifier la protection dans chaque dépôt. Ici, la présence du déclencheur donne un point de départ. Le risque dépend de ce qui se passe ensuite.
Utiliser les données de la phase d’évaluation
GitHub indique que la phase d’évaluation permet de repérer dans Insights les exécutions que la règle bloquerait. Commencez par cette liste et associez chaque workflow à une équipe responsable. Demandez quel service il rend et si ce service peut fonctionner avec un déclencheur moins privilégié ou des permissions plus étroites. Une vérification de code provenant d’un fork et une mise à jour d’étiquette n’ont pas forcément besoin du même contexte.
Si un workflow doit conserver ce déclencheur, GitHub prévoit de l’autoriser dans une politique d’événements Actions applicable. Sa documentation décrit aussi le ciblage de fichiers de workflow. L’autorisation est une décision sur un périmètre précis. Vérifiez les permissions requises, les données reçues et les commandes lancées avant de choisir où l’appliquer. Notre article sur le contrôle des secrets avant leur envoi aborde un mécanisme distinct. Dans ce cas, l’examen porte sur l’exécution de l’automatisation et les données auxquelles elle accède.
Ce qui change le 2 décembre
La règle par défaut concerne les dépôts publics sur GitHub Free, Team et Enterprise Cloud. L’annonce exclut les dépôts privés et internes ainsi que GitHub Enterprise Server. Pour une organisation qui utilise plusieurs offres, vérifiez le type et la visibilité du dépôt avant d’interpréter les résultats. Prévenez aussi les personnes chargées des demandes externes lorsque des vérifications habituelles sont susceptibles d’être interrompues.
Le premier test du 9 novembre donne une occasion d’observer l’effet réel de la politique. Si le comportement est attendu, consignez la décision et la procédure de revue. Si le blocage révèle une dépendance, traitez cette dépendance avant le deuxième essai. Vous saurez ainsi quelles demandes doivent continuer à avancer le jour où la règle deviendra permanente.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
