GitHub añade 48 IP para webhooks: permitirlas no sustituye la firma
Se abre un pull request, pero el bot de despliegue no responde. Puede que la petición ni siquiera llegue a la aplicación porque la bloquea el cortafuegos. El anuncio de GitHub del 29 de octubre afecta precisamente a esa ruta de entrada.
Tres rangos adicionales en el lado receptor
Los nuevos CIDR son 9.234.98.160/28, 9.234.98.176/28 y 9.234.106.48/28. Se aplican a las entregas de webhooks de github.com en todos los planes, incluido GitHub Enterprise Cloud. En una lista estática hay que añadirlos junto a los existentes, sin reemplazarlos.
Cada /28 contiene 16 direcciones: 48 en total. La imagen muestra un cálculo local real con ipaddress de Python; no cuenta cuentas ni servidores. Según GitHub, quien ya actualiza la lista mediante hooks en GET /meta no necesita otro cambio para esta ampliación.
La IP y la firma responden a preguntas distintas
La lista decide qué redes pueden alcanzar el receptor. Para ello corresponde hooks, no actions, destinado a otro recorrido de red de los runners. Recibir eventos y llamar desde CI a una API externa son direcciones diferentes.
Después hay que verificar X-Hub-Signature-256 con el secreto de ese webhook. GitHub genera HMAC-SHA256 con el secreto y el cuerpo. Calcule la firma a partir de los bytes originales y use una comparación de tiempo constante como hmac.compare_digest o crypto.timingSafeEqual. Una IP permitida no elimina esta comprobación.
Un JSON equivalente puede tener otros bytes
Convertir {"action":"opened"} en {"action": "opened"} añade un espacio. El significado permanece, pero la firma puede dejar de coincidir. El ejemplo local con un secreto público de demostración devuelve True para bytes idénticos y False con el espacio. No es una entrega real capturada de GitHub.
Conserve el cuerpo original antes de transformarlo y compruebe si el proxy o el framework lo altera. Poner el secreto en la URL del payload abriría otra vía de exposición. Manténgalo en la configuración segura del servidor.
Recuperar entregas sin repetir trabajo completado
Tras reparar la conexión, revise las entregas fallidas y reenvíe las necesarias. X-GitHub-Delivery conserva su valor al solicitar un reenvío. Distinga el trabajo completado del fallido que puede reanudarse; descartar cualquier ID ya visto también puede impedir la recuperación.
GitHub recomienda responder 2XX en diez segundos y usar una cola para tareas largas. Una validación seguida de recepción duradera y procesamiento reintentable conecta los tres momentos importantes: llegada, autenticación y finalización.