A multi-month study of Git commit signing: signing is not verifying

What happened on 2026-08-29

On 2026-08-29 at 14:07 UTC, Abubakar Sadiq Shittu, John Sadik and Scott Ruoti submitted v1 of 'A Multi-Month Study of Git Commit Signing' to arXiv. Over three months, 22 senior undergraduate and graduate students, used as proxies for junior developers, set up signing, used it across four coursework projects, extended it to a second device, examined an external repository containing anomalous commits and answered security-reasoning prompts. Almost all participants signed every commit and rated routine signing positively, but many struggled with setup, multi-device configuration and repository verification; over a quarter found no anomalous commits, and nearly half held at least one misconception about signing guarantees or key management.

What it means for protecting app logic

The link to app protection is the build chain. Obfuscation configs, keep rules and signing scripts determine how much protection a shipped package gets, and a single unreviewed change can quietly disable a protection or add a broad rule. Commit signing can provide provenance, but the paper is a reminder that its value depends on someone verifying signatures against authorized identities and correctly interpreting missing signatures and unknown keys. Enabling signing without verification offers more sense of security than security. As for limits, participants were students, so results do not transfer directly to experienced teams, and the study does not isolate whether difficulties came from tooling, education or understanding.

Checks you can run

Require signed commits on protected branches and verify them in CI against a team-maintained list of authorized keys, rather than only checking that a signature exists. Mark obfuscation configs, keep rules and signing and notarization scripts as files that need review by named owners, for example via CODEOWNERS. Write down procedures for key rotation, lost devices and departing members. Periodically sample the commits behind release builds to confirm every change to protection config has a traceable approval. Remember that a missing signature or an unknown key is a signal to investigate, not something to wave through.

Your checklist

• Verify commit signatures in CI against authorized keys
• Assign named reviewers to protection-related config files
• Document key rotation and offboarding procedures