Automated security check failing on PR integrated as a rebase

[alois-kende]

Hello everyone,

TL;DR: I automatically check for signatures on new commits and commits integrated straight as a rebase won't have one. Was it an error to integrate them like this or is my automated verification just a bad idea?

Long version:

I set up an automated job in my project that checks if there is a new release of vcpkg weekly to try and build it automatically if there is.
It also checks if every new commit is signed by a whitelisted signature to limit the risk that I build something corrupted / compromised.

It has worked decently for a couple months but today it failed.

The reason is that there was one PR (#52334) that was integrated, not as an automatically signed merged commit but as rebase integrating the original unsigned commits straight into the branch history.

Now, after checking manually, it seems like it was reviewed and there is probably no security issue here, but if it happens again, I don't know how or if I could or should automate such a check.

Since it seems to me that almost every single commit has been signed for a few years now (and even the tags for a couple months I believe), I wonder if the integration of unsigned commits like that was an error of if it something that is legitimate that could happen regularly.

I thank you deeply for all your work and I'm not throwing a stone at anyone, I'm just trying to understand if my "automated signature verification before integration" is a bad approach or if it might work.

Thanks a lot for your help and any insight :D

Aloïs

[ricardoofnl]

Your check caught a real thing, and your reading of it is correct. PR #52334 was integrated by rebasing the author's three original commits straight onto master, so they kept their original unsigned state with the maintainer as committer, instead of the usual squash commit that GitHub creates and signs with its web-flow key.

You can see the contrast on master right now:

• Normal path: committer GitHub, verified=true, one squashed commit per PR (GitHub signs it because GitHub created it when someone pressed "Squash and merge").
• PR [numactl] Add cmake config #52334: commits af073039 / 401a6a38 / 7a9a0ff2, committer Billy O'Neal, verified=false reason=unsigned.

Was it an error? Not a security one. Maintainers occasionally integrate a PR by rebasing/pushing from their own machine instead of using the GitHub merge button (to resolve conflicts locally, or to keep a multi-commit history intact). Done that way, the commits don't get GitHub's web-flow signature. Uncommon, legitimate, and it will happen again.

On whether per-commit signature verification is a good gate, I'd gently push back, for two reasons:

1. It's fragile: it false-positives in exactly this case (a legitimate manual push), so you get paged for non-events.
2. More importantly, it verifies less than it looks like. GitHub's web-flow signature only attests "this commit was created by GitHub when someone pressed merge in this repo". It says nothing about content integrity or review quality, and every squash-merge by anyone with write access carries the identical signature. So "signed by web-flow" is roughly equivalent to "arrived through microsoft/vcpkg", which you already get from cloning microsoft/vcpkg over TLS.

What actually gives you supply-chain integrity for vcpkg:

• Pin to a release tag and verify the tag signature, not each commit. Release tags are annotated and signed. The latest tag 2026.06.24 is verified=true (tagger Billy Robert O'Neal III). That's one signature to check per release, on the artifact that is actually meant to be consumed.
• Pin builtin-baseline to a commit you've decided to trust, and lean on vcpkg's content-addressing: every port version in versions/*.json is pinned to a git-tree SHA, and every upstream download in a portfile is pinned by SHA512. That protects the actual bytes you build, which per-commit signatures do not.

So the intent is right (gate on provenance), but the specific signal is both noisier and weaker than gating on the signed release tag plus vcpkg's git-tree/SHA512 pinning. I'd switch the weekly job to: watch for a new signed tag -> verify the tag -> build at that tag.

Hope that helps!