GitHub adiciona 48 IPs de webhook: a assinatura continua necessária
Um pull request é aberto, mas o bot de deploy fica em silêncio. A requisição pode ter parado no firewall antes de chegar à aplicação. O anúncio do GitHub de 29 de outubro trata desse caminho de entrada.
Três faixas adicionais no receptor
Os novos CIDRs são 9.234.98.160/28, 9.234.98.176/28 e 9.234.106.48/28. Valem para webhooks do github.com em todos os planos, incluindo GitHub Enterprise Cloud. Acrescente-os à lista estática sem substituir as faixas existentes.
Cada /28 contém 16 endereços, totalizando 48. A imagem mostra um cálculo local real com ipaddress do Python, não a quantidade de contas ou servidores. Segundo o GitHub, quem já atualiza a lista por hooks em GET /meta não precisa de outra alteração para esta adição.
IP e assinatura respondem a perguntas diferentes
A lista define quais redes podem alcançar o receptor. Use hooks, não actions, que descreve outro caminho dos runners. Receber eventos e chamar uma API externa a partir do CI são direções distintas.
Depois, valide X-Hub-Signature-256 com o secret desse webhook. O GitHub gera HMAC-SHA256 a partir do secret e do corpo. Recalcule sobre os bytes originais e compare em tempo constante com hmac.compare_digest ou crypto.timingSafeEqual. Um IP permitido não elimina essa etapa.
JSON equivalente pode ter bytes diferentes
Recriar {"action":"opened"} como {"action": "opened"} adiciona um espaço. O significado permanece, mas a assinatura pode mudar. No exemplo local com um secret público de demonstração, bytes iguais resultam em True e o espaço extra em False. Não é uma entrega real capturada do GitHub.
Preserve o corpo bruto antes de transformá-lo e examine possíveis mudanças no proxy ou framework. Colocar o secret na URL do payload abriria outra via de exposição. Mantenha-o na configuração segura do servidor.
Recuperar sem repetir o trabalho concluído
Após restaurar a rede, examine as entregas com falha e reenvie as necessárias. X-GitHub-Delivery mantém o valor no reenvio solicitado. Diferencie trabalho concluído de falhas retomáveis; descartar todo ID já visto pode impedir a própria recuperação.
O GitHub recomenda resposta 2XX em dez segundos e uma fila para tarefas longas. Conecte verificação, recebimento durável e estado de processamento que permita novas tentativas. Assim, os três CIDRs fazem parte do caminho de chegada, validação e conclusão.