48 nouvelles IP de webhook GitHub : la signature reste indispensable
Une pull request s’ouvre, mais le robot de déploiement reste silencieux. La requête est peut-être bloquée par le pare-feu avant même d’atteindre l’application. L’annonce GitHub du 29 octobre concerne ce trajet entrant.
Trois plages supplémentaires côté réception
Les nouveaux CIDR sont 9.234.98.160/28, 9.234.98.176/28 et 9.234.106.48/28. Ils concernent les webhooks de github.com pour toutes les offres, dont GitHub Enterprise Cloud. Ajoutez-les aux plages existantes d’une liste statique sans remplacer celles-ci.
Chaque /28 comprend 16 adresses, soit 48 au total. L’illustration présente un véritable calcul local avec ipaddress de Python, pas un nombre de comptes ou de serveurs. GitHub indique qu’aucune modification supplémentaire n’est nécessaire si la liste est déjà actualisée via hooks dans GET /meta.
L’adresse IP et la signature répondent à deux questions
La liste autorise certaines sources réseau à joindre le récepteur. Utilisez hooks, et non actions qui décrit un autre trajet des runners. Un service recevant des événements et un job CI appelant une API externe n’empruntent pas le même sens de circulation.
Vérifiez ensuite X-Hub-Signature-256 avec le secret du webhook. GitHub calcule un HMAC-SHA256 à partir du secret et du corps. Recalculez-le sur les octets originaux et comparez en temps constant, avec hmac.compare_digest ou crypto.timingSafeEqual. Une IP autorisée ne remplace pas cette vérification.
Un JSON équivalent peut changer d’octets
Resérialiser {"action":"opened"} en {"action": "opened"} ajoute un espace. Le sens reste le même, mais la signature peut différer. Notre exemple local utilise un secret public de démonstration : True pour les mêmes octets, False après ajout de l’espace. Ce n’est pas une livraison GitHub capturée.
Conservez le corps brut avant toute transformation et examinez les changements éventuels du proxy ou du framework. Placer le secret dans l’URL du payload créerait un autre risque de divulgation. Gardez-le dans une configuration serveur sécurisée.
Reprendre une livraison sans répéter le travail terminé
Après réparation du réseau, examinez les livraisons échouées et relancez celles qui le nécessitent. X-GitHub-Delivery reste identique lors d’une nouvelle livraison demandée. Distinguez les traitements terminés des échecs reprenables : rejeter tout identifiant déjà vu peut bloquer la reprise.
GitHub recommande une réponse 2XX sous dix secondes et une file pour les traitements longs. Reliez vérification, réception durable et état de traitement réessayable. Les trois CIDR prennent alors leur place dans un parcours allant de l’arrivée à l’achèvement.