48 neue GitHub-Webhook-IP-Adressen: Die Signatur bleibt entscheidend
Ein Pull Request ist offen, doch der Deployment-Bot bleibt still. Vielleicht erreicht die Anfrage die Anwendung gar nicht, weil die Firewall sie abweist. GitHubs Mitteilung vom 29. Oktober betrifft genau diesen eingehenden Weg.
Drei zusätzliche Netze für den Empfänger
Neu sind 9.234.98.160/28, 9.234.98.176/28 und 9.234.106.48/28. Sie gelten für Webhook-Zustellungen von github.com in allen Tarifen einschließlich GitHub Enterprise Cloud. Ergänzen Sie statische Freigabelisten um diese Netze, ohne die bisherigen Einträge zu ersetzen.
Jedes /28 enthält 16 Adressen, zusammen 48. Die Abbildung zeigt eine tatsächliche lokale Berechnung mit Python ipaddress, keine Anzahl von Konten oder Servern. Wer die Liste bereits über GET /meta und dessen Feld hooks aktuell hält, muss laut GitHub hierfür nichts zusätzlich ändern.
IP-Freigabe und Signatur beantworten verschiedene Fragen
Eine Freigabeliste bestimmt, aus welchen Netzen Anfragen eintreffen dürfen. Dafür ist hooks zuständig, nicht actions für den anderen Netzwerkpfad der Actions-Runner. Ein empfangender Deployment-Dienst und ein CI-Job mit ausgehenden API-Aufrufen haben unterschiedliche Richtungen.
Prüfen Sie anschließend X-Hub-Signature-256 mit dem für diesen Webhook hinterlegten Secret. GitHub berechnet HMAC-SHA256 aus Secret und Nutzlast. Verwenden Sie die unveränderten Request-Bytes und einen zeitkonstanten Vergleich wie hmac.compare_digest oder crypto.timingSafeEqual. Eine erlaubte IP ersetzt diesen Schritt nicht.
Gleicher JSON-Inhalt, andere Bytes
Aus {"action":"opened"} kann nach erneutem Serialisieren {"action": "opened"} werden. Das zusätzliche Leerzeichen verändert die Bytes. Im lokalen Beispiel mit einem öffentlichen Demo-Secret ergibt dieselbe Nutzlast True, die geänderte False. Das ist kein Mitschnitt einer GitHub-Zustellung.
Sichern Sie die Originalbytes vor jeder Umwandlung und prüfen Sie gegebenenfalls Proxy und Framework. Ein Secret in der Payload-URL würde einen neuen Offenlegungsweg schaffen. Es gehört in die sichere Serverkonfiguration.
Wiederherstellung ohne doppelte abgeschlossene Arbeit
Nach der Netzwerkreparatur lassen sich fehlgeschlagene Zustellungen prüfen und erneut senden. X-GitHub-Delivery bleibt bei einer angeforderten Wiederzustellung gleich. Unterscheiden Sie abgeschlossene Arbeit von fehlgeschlagenen, fortsetzbaren Vorgängen, statt jede bekannte ID pauschal zu verwerfen.
GitHub empfiehlt eine 2XX-Antwort innerhalb von zehn Sekunden und eine Queue für längere Verarbeitung. Verbinden Sie Signaturprüfung, dauerhafte Annahme und wiederholbare Verarbeitung. So wird aus drei neuen CIDRs eine verständliche Kette von Eingang, Prüfung und Abschluss.