Zotonic Deployment with Github: Post-Receive Authenticity Challenges

Github's Post-Receive Hooks are incredibly easy to set up, but there's a snag I really don't like: there is no defined way to authenticate the sender. Github only provides a payload, but no tokens or signature of any kind.

I contrast PayPal IPN has a cryptographic verification process that clients like mod_paypal can use to verify that the request is authentic. In fairness Github is providing this as a significant convenience for more hobbyist use cases and it is clearly much less sensitive info than a payment transaction. However, it does limit what you should do with the information since it cannot be authenticated.

The best mechanism I can think of at the moment is to verify the sender's IP. Github lists 207.97.227.253 and 50.57.128.197 as the originating servers for the Service Hooks configuration page. IP spoofing is mostly impractical, but other manipulation of payload is easily possible and the fact that a Post-Receive has been triggered is the only remotely safe thing to assume upon successfully providing a response to Github. Host-based authentication really makes me uneasy, and basing it solely on IP address is particularly poor. Beggars can't be choosers.

Of great interest is whether or not Github will tolerate slow, non-responsive, or HTTP error responses. Ideally I would respond immediately with a HTTP 400 error code just to keep snooping URL scanners off the scent. It's not documented, and based on the purpose Github should not care either way as long as it doesn't block.