48 новых IP для GitHub webhook: список разрешений не заменяет подпись
Pull request открыт, а бот развёртывания молчит. Возможно, запрос остановился на межсетевом экране и до приложения не дошёл. Объявление GitHub от 29 октября касается именно входящего пути.
Три дополнительные сети на стороне получателя
Новые CIDR: 9.234.98.160/28, 9.234.98.176/28 и 9.234.106.48/28. Они относятся к webhook github.com на всех тарифах, включая GitHub Enterprise Cloud. Добавьте их к существующим записям статического списка, не заменяя старые диапазоны.
В каждом /28 по 16 адресов, всего 48. Иллюстрация показывает реальное локальное вычисление Python ipaddress, а не число аккаунтов или серверов. По сообщению GitHub, отдельные изменения не нужны, если список уже обновляется через hooks в GET /meta.
IP и подпись отвечают на разные вопросы
Список определяет, из каких сетей запросы могут попасть к получателю. Для этого нужен hooks, а не actions, описывающий другой путь runner. Приём событий и вызов внешнего API из CI имеют разные направления.
Затем проверьте X-Hub-Signature-256 с secret данного webhook. GitHub формирует HMAC-SHA256 из secret и тела. Рассчитайте его по исходным байтам и сравните за постоянное время через hmac.compare_digest или crypto.timingSafeEqual. Разрешённый IP не отменяет эту проверку.
Одинаковый смысл JSON не означает одинаковые байты
Преобразование {"action":"opened"} в {"action": "opened"} добавляет пробел. Смысл сохраняется, подпись может измениться. Локальный пример с публичным демонстрационным secret даёт True для одинаковых байтов и False после добавления пробела. Это не запись реальной доставки GitHub.
Сохраняйте необработанное тело до преобразований и проверяйте изменения прокси или фреймворка. Secret в URL payload создал бы новый канал раскрытия. Храните его в защищённой конфигурации сервера.
Восстановление без повторения завершённой работы
После восстановления сети просмотрите неудачные доставки и повторите нужные. X-GitHub-Delivery при запрошенной повторной доставке остаётся прежним. Отличайте завершённую работу от ошибок, допускающих продолжение: отбрасывание всех известных ID может помешать восстановлению.
GitHub рекомендует ответ 2XX за десять секунд и очередь для долгой обработки. Свяжите проверку подписи, надёжный приём и состояние с возможностью повтора. Тогда три CIDR станут частью понятного пути от поступления до завершения.