Use HMAC for signing webhooks #1755

New Issue

GiteaMirror · 2025-11-02T04:12:19-06:00

GiteaMirror commented

2025-11-02 04:12:19 -06:00

Originally created by @captn3m0 on GitHub (May 5, 2018).

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

Originally created by @captn3m0 on GitHub (May 5, 2018). - Gitea version (or commit ref): 1.4.1 - Git version: NA - Operating system: NA - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] 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](https://developer.github.com/webhooks/securing/#validating-payloads-from-github)] ## Screenshots  ![image](https://user-images.githubusercontent.com/584253/39667842-84589710-50dc-11e8-8d82-99823cb834cd.png)

GiteaMirror added the type/enhancement topic/security labels 2025-11-02 04:12:19 -06:00

GiteaMirror closed this issue

2025-11-02 04:12:19 -06:00

GiteaMirror commented

2025-11-02 04:12:19 -06:00

@bradrydzewski commented on GitHub (Jul 6, 2018):

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}

@bradrydzewski commented on GitHub (Jul 6, 2018): 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}`

GiteaMirror commented

2025-11-02 04:12:20 -06:00

@simbo1905 commented on GitHub (Jan 2, 2019):

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.

@simbo1905 commented on GitHub (Jan 2, 2019): 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.

GiteaMirror commented

2025-11-02 04:12:20 -06:00

@titpetric commented on GitHub (Mar 6, 2019):

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 commented on GitHub (Mar 6, 2019): 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.

GiteaMirror commented

2025-11-02 04:12:20 -06:00

@titpetric commented on GitHub (Mar 6, 2019):

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.

@titpetric commented on GitHub (Mar 6, 2019): I tracked down the relevant commit adding this in gogs: [3609efe2](https://github.com/gogs/gogs/commit/3609efe2e3d562547ae6497d67d56be7626727d0). The signature header there is prefixed with `X-Gogs`, suggesting we should have `X-Gitea` here.

GiteaMirror commented

2025-11-02 04:12:20 -06:00

@lunny commented on GitHub (Mar 17, 2019):

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

@lunny commented on GitHub (Mar 17, 2019): @titpetric Nobody are working on this. Please send a PR to fix this.

GiteaMirror commented

2025-11-02 04:12:20 -06:00

@titpetric commented on GitHub (Mar 17, 2019):

Migrated to drone, which supports the current Gitea payloads, was for the best.

@titpetric commented on GitHub (Mar 17, 2019): Migrated to drone, which supports the current Gitea payloads, was for the best.

GiteaMirror commented

2025-11-02 04:12:21 -06:00

@simbo1905 commented on GitHub (Mar 17, 2019):

We are using adnanh/webhook and wrote matching rules that work for either Gitea or Github. The point here is not that you cannot match on a secret in the body the point is that it is a less secure approach.

@simbo1905 commented on GitHub (Mar 17, 2019): We are using adnanh/webhook and wrote matching rules that work for either Gitea or Github. The point here is not that you cannot match on a secret in the body the point is that it is a less secure approach.

GiteaMirror commented

2025-11-02 04:12:21 -06:00

@titpetric commented on GitHub (Mar 17, 2019):

@simbo1905 I agree 100%, but effectively this either means choose a limited set of CI’s that support Gitea, or switch out Gitea for a more secure alternative. I didn’t necessarily want to PR against abstuse CI and at the same time, any PR against gitea might take weeks or months in the pipeline before being merged (if). The reality is that we needed to choose what works without having to build it out on either side.

@titpetric commented on GitHub (Mar 17, 2019): @simbo1905 I agree 100%, but effectively this either means choose a limited set of CI’s that support Gitea, or switch out Gitea for a more secure alternative. I didn’t necessarily want to PR against abstuse CI and at the same time, any PR against gitea might take weeks or months in the pipeline before being merged (if). The reality is that we needed to choose what works without having to build it out on either side.

GiteaMirror commented

2025-11-02 04:12:21 -06:00

@lunny commented on GitHub (Mar 18, 2019):

@titpetric Not all PRs took a long time. For those PRs which needs more review and tests, we have to spend more time on it to reduce bugs or regressions . A PR to fix this issue is welcome.

@lunny commented on GitHub (Mar 18, 2019): @titpetric Not all PRs took a long time. For those PRs which needs more review and tests, we have to spend more time on it to reduce bugs or regressions . A PR to fix this issue is welcome.

GiteaMirror commented

2025-11-02 04:12:21 -06:00

@urbanswelt commented on GitHub (Mar 25, 2019):

I am here to test the PR =)

@urbanswelt commented on GitHub (Mar 25, 2019): I am here to test the PR =)

GiteaMirror commented

2025-11-02 04:12:21 -06:00

@techknowlogick commented on GitHub (Mar 25, 2019):

@urbanswelt please see linked PR

@techknowlogick commented on GitHub (Mar 25, 2019): @urbanswelt please see linked PR

GiteaMirror commented

2025-11-02 04:12:22 -06:00

@zobo commented on GitHub (Mar 26, 2019):

Ah.. Missed it by a day :) https://github.com/go-gitea/gitea/pull/6430

Btw: I also added Header("X-Hub-Signature", "sha256=" + t.Signature). to be compatible with more clients.

@zobo commented on GitHub (Mar 26, 2019): Ah.. Missed it by a day :) https://github.com/go-gitea/gitea/pull/6430 Btw: I also added Header("X-Hub-Signature", "sha256=" + t.Signature). to be compatible with more clients.

GiteaMirror commented

2025-11-02 04:12:22 -06:00

@urbanswelt commented on GitHub (Mar 27, 2019):

@techknowlogick

Back from Testing:

Fresh compiled from Master branch today and initial setup done.

Signature would be generated when we fill up the "Secret" field.

#6430 will handle the json body if i see that correct.
Perfect work so far ! ;-)

@urbanswelt commented on GitHub (Mar 27, 2019): @techknowlogick Back from Testing: Fresh compiled from Master branch today and initial setup done. Signature would be generated when we fill up the "Secret" field. ![image](https://user-images.githubusercontent.com/2138928/55069250-e38b3600-5083-11e9-89c8-c5c06ee9a469.png) #6430 will handle the json body if i see that correct. Perfect work so far ! ;-)

GiteaMirror commented

2025-11-02 04:12:22 -06:00

@zobo commented on GitHub (Mar 27, 2019):

Correct. Should I create a different issue to track that part?

@zobo commented on GitHub (Mar 27, 2019): Correct. Should I create a different issue to track that part?

GiteaMirror referenced this issue

2025-11-02 12:00:48 -06:00

[PR #1755] [MERGED] Add Gitea Webhook #16035

Sign in to join this conversation.