typo fix in docs/standards/signing-code-commits.md

UKHomeOffice · Nov 26, 2024 · fe0cda8 · fe0cda8
1 parent a5e03b7
commit fe0cda8
Showing 1 changed file with 3 additions and 3 deletions.
diff --git a/docs/standards/signing-code-commits.md b/docs/standards/signing-code-commits.md
@@ -2,7 +2,7 @@
 layout: standard
 order: 1
 title: Signing code commits
-date: 2023-09-08
+date: 2024-11-26
 id: SEGAS-00009
 tags:
   - Source management
@@ -20,7 +20,7 @@ related:
 
 Signing code commits means that each developer has a private/public key pair assigned to them, usually this is generated by the developer on their local machine using a key generation tool. The private key is kept secret on the developers machine and the public key is deployed to their account with the source code management system (e.g. GitHub, GitLab or Bitbucket). When commits are pushed, they are digitally signed using the private key, and then verified by the source code management system. Subsequently, anyone viewing the commit in the repository will be able to cryptographically verify that the commit they are looking at was authored and signed by the developer that committed the change.
 
-When commit signing is not enforced, it is feasible for code to be committed with author information other than that of the developer committing the change. It is essential that all code changes can be correctly attributed to the developer that made the change, i.e. that they are traceable, auditable and enable accountability. 
+When commit signing is not enforced, it is feasible for code to be committed with author information other than that of the developer committing the change. It is essential that all code changes can be correctly attributed to the developer that made the change, i.e. that they are traceable, auditable and enable accountability.
 
 ---
 
@@ -42,7 +42,7 @@ Guidance on configuring git commit signing with common source code management sy
 
 While commit signing can often be enforced in the global configuration of source code management systems, this is not always implemented. Engineering teams must ensure that all of their repositories are configured to require commits be signed. Guidance on configuration for common source code management systems is available as below.
 
-- [GitHub - requiring commit signing with branch protetion rules](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits) - generally, this should be configured for the main branch at minimum. Dependent on your branching and release strategies it may need to be configured more widely, to ensure that only signed commits are promoted to higher environments
+- [GitHub - requiring commit signing with branch protection rules](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits) - generally, this should be configured for the main branch at minimum. Dependent on your branching and release strategies it may need to be configured more widely, to ensure that only signed commits are promoted to higher environments
 - [Bitbucket - using repository hooks](https://confluence.atlassian.com/bitbucketserver/using-repository-hooks-776639836.html) - Bitbucket has default hooks for verifying committers and commit signatures
 - [GitLab - push rules](https://docs.gitlab.com/ee/user/project/repository/push_rules.html#prevent-unintended-consequences) - the 'Reject unsigned commits' rule should be enabled. Be sure to understand how this rule behaves with the GitLab UI and Web IDE