GitHub menambah 48 IP webhook: daftar izin tetap perlu tanda tangan
Pull request terbuka, tetapi bot deployment diam. Permintaan mungkin ditolak firewall sebelum mencapai aplikasi. Pengumuman GitHub pada 29 Oktober menyangkut jalur masuk tersebut.
Tiga rentang tambahan di sisi penerima
CIDR baru adalah 9.234.98.160/28, 9.234.98.176/28, dan 9.234.106.48/28. Rentang ini berlaku untuk pengiriman webhook github.com pada semua paket, termasuk GitHub Enterprise Cloud. Tambahkan ke daftar izin statis tanpa mengganti rentang lama.
Setiap /28 mencakup 16 alamat, total 48. Gambar menampilkan perhitungan lokal nyata memakai ipaddress Python, bukan jumlah akun atau server. Menurut GitHub, tidak perlu perubahan tambahan jika daftar sudah diperbarui melalui hooks dari GET /meta.
IP dan tanda tangan menjawab pertanyaan berbeda
Daftar izin memilih jaringan sumber yang boleh mencapai penerima. Gunakan hooks, bukan actions yang berkaitan dengan jalur runner. Layanan penerima event dan job CI yang memanggil API eksternal bergerak ke arah jaringan berbeda.
Setelah itu, verifikasi X-Hub-Signature-256 dengan secret webhook tersebut. GitHub membuat HMAC-SHA256 dari secret dan isi permintaan. Hitung dari byte asli lalu bandingkan dengan cara berwaktu konstan seperti hmac.compare_digest atau crypto.timingSafeEqual. IP yang diizinkan tidak menggantikan pemeriksaan ini.
JSON setara belum tentu memiliki byte sama
Mengubah {"action":"opened"} menjadi {"action": "opened"} menambahkan spasi. Maknanya sama, tetapi tanda tangannya dapat berbeda. Contoh lokal dengan secret demonstrasi publik menghasilkan True untuk byte identik dan False setelah spasi ditambah. Ini bukan rekaman pengiriman GitHub nyata.
Simpan body mentah sebelum transformasi dan periksa kemungkinan perubahan oleh proxy atau framework. Menaruh secret di URL payload justru membuka jalur kebocoran. Simpan di konfigurasi server yang aman.
Pulihkan pengiriman tanpa mengulang pekerjaan selesai
Sesudah jaringan pulih, periksa pengiriman gagal dan kirim ulang yang diperlukan. X-GitHub-Delivery tetap sama pada pengiriman ulang yang diminta. Bedakan pekerjaan selesai dari kegagalan yang bisa dilanjutkan; membuang semua ID yang pernah terlihat dapat menghalangi pemulihan.
GitHub menyarankan respons 2XX dalam sepuluh detik dan antrean untuk pemrosesan panjang. Hubungkan verifikasi, penerimaan persisten, dan status yang dapat dicoba ulang. Dengan begitu, tiga CIDR menjadi bagian jalur kedatangan, validasi, dan penyelesaian.