Use HMAC for signing webhooks

[captn3m0]

• Gitea version (or commit ref): 1.4.1
• Git version: NA
• Operating system: NA
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Several tools rely on standard GitHub webhooks, which include a X-Hub-Signature header to validate the webhook. Gitea sends the secret in the payload JSON itself, which doesn't work for all services.

The standard github event signature is a simple HMAC-SHA1 of the request payload with the secret as the key. [Docs]

Screenshots

[bradrydzewski]

This would be a nice feature. For reference, here are what some of the other providers are doing:

• GitLab sends the secret in X-Gitlab-Token: {secret}
• GitHub sends the webhook hmac signature in X-Hub-Signature: sha1={hash}
• Bitbucket server sends the webhook hmac in X-Hub-Signature: sha256={hash}
• Gogs sends the webhook hmac signature in X-Hub-Signature: {hash}

[simbo1905]

Is there a security label that can be added to this ticket? The current method of sending the secret in the payload in plain text is considerably less secure than GitHub, GitLab, BitBucket and Gogs that are hashing the payload.

[titpetric]

Is somebody working on this? I'd like to implement it against the GitHub specs (HMAC-SHA1), if somebody volunteers to field the PR. Would love to see this in a future version to integrate against Abstruse CI.

[titpetric]

I tracked down the relevant commit adding this in gogs: 3609efe2. The signature header there is prefixed with X-Gogs, suggesting we should have X-Gitea here.

[lunny]

@titpetric Nobody are working on this. Please send a PR to fix this.