Rewording on commit signing

Author: andyblundell

practices/securing-repositories.md

@@ -59,7 +59,7 @@ This minimum set of requirements should be implemented alongside other relevant
   - Code reviews must be approved by at least one code owner.
   - You may want to require multiple code owners to review pull requests.
 - Commits must be <!-- markdown-link-check-disable -->[signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits)<!-- markdown-link-check-enable --> and verified before merging.
-  - Git treats authentication and identity separately - any authenticated user can impersonate another developer when committing code. This means that even if a junior account is compromised it could have significant consequences, for example impersonating the lead developer in the hope of an easy merge. Only by requiring signing can identity truly be verified.
+  - Git treats authentication and identity separately - without a signature, a git commit could have come from anyone, and the email address attached to a commit can be made up. A compromised junior account can apply the lead developer's email address to a bad commit in the hope of an easy merge to `main`. When github verifies the signature of a commit before a merge, it tells us that it was committed by who it claims to have been signed by. It may legitimately be uploaded by someone else but as long as github can verify the signature, we can be sure of the authorship.
   - For further details, please see [Setup Guides](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline.
 - Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option).
 - Merging must be blocked if the branch is not up to date.