-
Bug
-
Resolution: Fixed
-
Major
Looking at this code https://github.com/jenkinsci/github-plugin/blob/68ceb5960549c6a5ce55c5288c7eaabbbb3719a2/src/main/java/org/jenkinsci/plugins/github/webhook/RequirePostWithGHHookPayload.java#L145
This means that if a secret is configured but the webhook doesn't have a signature, the request is allowed. I would expect that is a secret is configured, any webhook without a signature should be rejected, i.e.:
if(Optional.fromNullable(secret).isPresent()) { if(signHeader.isPresent()) { // Do the existing check } else { // fail the hook } }
- is duplicated by
-
JENKINS-48762 Unsigned Webhooks are always accepted
-
- Resolved
-
- links to
This seems to have been introduced by the "fix" of -
- (commit 05ad7b42033)... I obviously don't know all the ramifications, but the description in -JENKINS-37481- isn't really clear about the webhook configuration after the upgrade. It sounds like the webhook did have a signature token and the plugin's configuration wasn't updated accordingly after the update from 1.20.0 to 1.21.0.JENKINS-37481All of this to say that I don't quite understand why this bug has been fixed this way. The /github-webhook/ endpoint is inbound, so the Jenkins configuration should have priority over what's coming from a request (imho), as it acts similarly to a whitelist. Otherwise, anyone can ping a Jenkins instance visible from the internet and omit this header and the request will be processed successfully. Maybe a distinct option in the UI to disable the security checks would be more explicit instead of using no credentials?
Any idea when this can be fixed?