GitHub aggiunge 48 IP per i webhook: resta necessaria la firma
Si apre una pull request, ma il bot di deployment tace. La richiesta potrebbe essere fermata dal firewall prima di raggiungere l’applicazione. L’annuncio GitHub del 29 ottobre riguarda questo percorso in ingresso.
Tre intervalli aggiuntivi sul ricevitore
I nuovi CIDR sono 9.234.98.160/28, 9.234.98.176/28 e 9.234.106.48/28. Valgono per i webhook di github.com su tutti i piani, compreso GitHub Enterprise Cloud. Aggiungeteli agli intervalli esistenti della lista statica senza sostituirli.
Ogni /28 contiene 16 indirizzi, per un totale di 48. L’immagine mostra un calcolo locale effettivo con ipaddress di Python, non il numero di account o server. Secondo GitHub non servono altri interventi se la lista è già aggiornata tramite hooks di GET /meta.
IP e firma rispondono a domande diverse
La lista decide quali reti possono raggiungere il ricevitore. Serve hooks, non actions, che descrive un diverso percorso dei runner. Ricevere eventi e chiamare un’API esterna da CI sono direzioni distinte.
Verificate poi X-Hub-Signature-256 con il secret del webhook. GitHub genera HMAC-SHA256 dal secret e dal corpo. Ricalcolatelo sui byte originali e usate un confronto a tempo costante come hmac.compare_digest o crypto.timingSafeEqual. Un IP ammesso non sostituisce questa verifica.
JSON equivalente, byte diversi
Riscrivere {"action":"opened"} come {"action": "opened"} aggiunge uno spazio. Il significato resta, ma la firma può cambiare. L’esempio locale con un secret pubblico dimostrativo produce True per byte identici e False con lo spazio. Non è una consegna GitHub catturata.
Conservate il corpo grezzo prima di trasformarlo e controllate eventuali modifiche del proxy o del framework. Inserire il secret nell’URL del payload creerebbe un’altra esposizione. Mantenetelo nella configurazione sicura del server.
Ripristinare senza duplicare il lavoro completato
Riparata la rete, controllate le consegne fallite e ripetete quelle necessarie. X-GitHub-Delivery mantiene lo stesso valore nella riconsegna richiesta. Distinguete il lavoro completato dagli errori riprendibili: scartare ogni ID già visto può impedire anche il recupero.
GitHub consiglia una risposta 2XX entro dieci secondi e una coda per il lavoro lungo. Collegate verifica, accettazione persistente e stato riprovabile. I tre CIDR si inseriscono così nel percorso dall’arrivo alla conclusione.