Github webhook is throwing an error.

[DevSlashRichie]

It seems that when I receive a webhook from github it throws the following error.

{"level":"error","ts":"2022-01-05T07:01:11.885Z","logger":"receiver-server","msg":"unable to validate payload","reconciler kind":"Receiver","name":"github-receiver","namespace":"flux-system","error":"the GitHub signature header is invalid, err: payload signature check failed"}

[kingdonb]

That's interesting!

flux-recv/github.go

Line 9 in 50473d9

"github.com/google/go-github/v28/github"

The flux-recv is on an older version of the github go client package. We are on v28 and the latest is v41 from about two months ago.

It is possible that upgrading to this newer version will resolve the issue. Maybe GitHub changed their signature profile in the interceding releases, and this is expected. I'm not sure (I haven't read the changelogs)

It should be noted that flux-recv and Flux v1 are replaced with Flux v2, which has passed feature parity some time last year (6 months ago or longer) and there should be little to no reason remaining to run Flux v1. In v2, the flux-recv project is gone and replaced with a Receiver CRD and notification-controller, which are first-class parts of the new GitOps Toolkit design. Regardless of that, thank you for reporting the issue here!

If you are using flux-recv, and have any Go capabilities, are you interested in submitting the PR? I do not have maintainer access on this repo and cannot guarantee merging it / cutting of a release, as I'm not sure of the support status of flux-recv but, there's also something very satisfying about scratching your own itch. (If you need help to get it going, I'm glad to take a look at it with you.)

[kingdonb]

I bet it's this same issue: google/go-github#592 (comment)

[kingdonb]

I don't have this issue reproduced myself, but I made a new image that you can try and see if it resolves your issue:

kingdonb/flux-recv:821995c3

Please give this a try and let me know if it helps!

[DevSlashRichie]

Thanks I will asap.

[DevSlashRichie]

Actually I made a mistake because I am using Flux v2

[kingdonb]

Whew that is a relief :D I should have guessed from "reconciler kind":"Receiver"

Then the place for your issue is: https://github.com/fluxcd/notification-controller

Please provide more information if you report this again, I don't know what additional info is necessary to clear up the report, but there is something special about your setup as I will tell you that I have GitHub Webhook receivers configured and I've just tested them on my Flux v0.24.1 installation, the signatures work today same as yesterday.

[DevSlashRichie]

Whew that is a relief :D I should have guessed from "reconciler kind":"Receiver"

Then the place for your issue is: https://github.com/fluxcd/notification-controller

Please provide more information if you report this again, I don't know what additional info is necessary to clear up the report, but there is something special about your setup as I will tell you that I have GitHub Webhook receivers configured and I've just tested them on my Flux v0.24.1 installation, the signatures work today same as yesterday.

Well, I am using webhook for the whole organization, not sure if that's a problem. Besides that I just followed the Getting Started tutorial.

[kingdonb]

@RicardoRMDev I think that webhooks are meant to be set up on each repo. Webhooks for the entire organization have been discussed recently, I think this is also a use case that we want to support, but it is not yet a supported feature.

Each repository currently requires to be individually configured in order to receive webhooks from GitHub.

Would you please file this as an issue on notification-controller? It will help to prioritize if we know there are users who would like support for this feature. (I have used an organization-wide webhook with Jenkins before, and it's an incredible config time savings, as well as reducing lead time to deploy a new app with full support in the org, it also reduces the friction and potential for misconfiguration on each repo, so I completely understand the value of this feature!)