Signature Verification for Commits Merged via UI

[squat]

I've enabled signature verification on my GitHub Source custom resource. Everything works fine when I commit directly to the main branch and push the commits to origin: the source-controller can verify my signatures and flux is happy. However, when I instead commit to a branch, make a pull request using the GitHub UI, and then merge the commit, the source-controller is not able to verify the commit signature.

I understand that all commits that are merged through the GitHub UI are signed with GitHub's web-flow key: https://github.com/web-flow.gpg. Nevertheless, when I add this key to my Secret, the source-controller is still unsatisfied and complains that the signature is not valid for my email address, which I guess makes sense because the identity of the key and the identity associated with the commit do not match. The source-controller logs errors like:

{"level":"error","ts":"2021-08-22T16:39:16.625Z","logger":"controller.gitrepository","msg":"Reconciler error","reconciler group":"source.toolkit.fluxcd.io","reconciler kind":"GitRepository","name":"flux-system","namespace":"flux-system","error":"PGP signature '-----BEGIN PGP SIGNATURE-----\n\nwsBcBAABCAAQBQJhInzQCRBK7hj4Ov3rIwAAJm8IAKdp4Q8E1sw9letIap+ClVCt\nHK1My0Lk/1E1QQDIHFXbX2wDdi3Jd6ouT7ZzTy7snpCn/tgraWZjhU6ir21Er6Uc\ngFiKQqKlqHvd9ksLrgRlAz0OQXvluQ0S0c9C6JXeWDYB8KjEZwa40uc4I+mbhVrE\nOx4hmzAzGeFvNnJ/dRc/J046lbDtY+1Gf+Nz9zpSbLYYkrFqsBHauoRETLBsoCAl\ndiN0fhxZI4zvzkI/iAsEf8G6uRBYjPoyLa8DjSH9QiswWr+vfcvu/pgg4lQevtMe\niMowecGm9bqZH3WqYDweUNfCUIEk0Cs4dO5hUmvuH66GIiYrsJobOlfoPCpvvlc=\n=d0Xg\n-----END PGP SIGNATURE-----\n\n' of '{Lucas Servén Marín [email protected] 2021-08-22 18:35:28 +0200 +0200}' can't be verified"}

Is there any way to support verifying commit signatures and still use a pull-request workflow with the source-controller?

[oliverbaehler]

Don't create merge commits on pull requests, use fasforward instead. At least that's my current solution.

[squat]

Is that possible through the GitHub UI?

[oliverbaehler]

It's a setting per repository. See whenever you merge a branch the default behavior is that a merge commit is created which combines the two refs. But in your case this merge commit has no signature. To avoid this problem you simply should not create merge commits. I am working with GitLlab and there it's possible to create Fast-Forward MRs, which solve this problem (https://docs.gitlab.com/ee/user/project/merge_requests/fast_forward_merge.html).

Have you tried with local merge, where you can sign the merge commit? https://stackoverflow.com/questions/49879963/how-squash-and-merge-a-pull-request-with-gpg-signing-via-command-line

[squat]

Have you tried with local merge, where you can sign the merge commit?

Ah, yes of course, however, this is hardly a nice workflow. It means that at the end of the day someone has to be responsible for checking out out all PRs locally and run some operations manually. This means no "auto-merge" when all CI checks pass and it's somewhat of a step backwards in continuous integration :/

[oliverbaehler]

Yeah i Know what you mean, it's not the best solution. I don't know maybe you could integrate that step as well into your CI system. We have a robot user that also makes gpg signed commits that are verified.

Besides that there isn't any other way to do it (that I know of). Switching to GitLab which supports FF Pull Requests via UI might be the easiest.

[squat]

Re: bots /GitLab: yes totally. The other idea that came to mind now was to write a bot that does the FF merges for me and updates/closes the PR

[raffis]

I came across this today as well. As I see this gpg verification with github/proctect main branch currently makes no sense. Although this is certainly not a problem with flux but rather github.

If I merge the pr via merge commit I end up with my commits signed but HEAD is signed by githubs key and not mine. The same happens with squash and merge pr though I only end up with one commit which again is signed by the github key. And with the merge and rebase option the commits are not signed at all.

Even if adding the github pub key to the chain would work it kinda defeats the purpose of commit verification in the first place. I want to secure myself if somebody manages to get into my gh account. The attacker could just bypass branch protection and let github merge a pr with a malicous change which would be signed by github in the end, or am I missing something?

I don't see a solution currently for this. It would be nice to have this documented that this will not work with a github pull request workflow. I can open a pr if thats the case.