<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=384195) </details> <!--IssueSummary end--> <!-- Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan --> ## Why are we doing this work <!-- A brief explanation of the why, not the what or how. Assume the reader doesn't know the background and won't have time to dig-up information from comment threads. --> In order for an SSH commit signature to be considered valid, the user who signed the commit needs to have the SSH key associated with the account, and the email address on the commit also need to be associated with their account and confirmed. If someone fixes these things after their commit has been pushed, the commit will continue to remain in an unverified state. When an email or ssh key is updated, when should refresh the status of associated signatures so that the status can change from "unverified" to "verified" when a user fixes their email or keys. For GPG keys, we do this via `InvalidGpgSignatureUpdateWorker`. We can implement a similar worker for SSH signatures. - https://gitlab.com/gitlab-org/gitlab/-/blob/ea19eb139eb86bee675af39a308193e9724a6fe2/app/models/email.rb#L15 - https://gitlab.com/gitlab-org/gitlab/-/blob/ea19eb139eb86bee675af39a308193e9724a6fe2/app/models/gpg_key.rb#L43 ## Non-functional requirements <!-- Add details for required items and delete others. --> - [ ] Documentation: - [ ] Feature flag: - [ ] Performance: - [ ] Testing: ## Implementation plan <!-- Steps and the parts of the code that will need to get updated. The plan can also call-out responsibilities for other team members or teams and can be split into smaller MRs to simplify the code review process. e.g.: - MR 1: Part 1 - [ ] ~frontend Step 1 - [ ] ~frontend Step 2 - MR 2: Part 2 - [ ] ~backend Step 1 - [ ] ~backend Step 2 - MR 3: Part 3 - [ ] ~frontend Step 1 - [ ] ~frontend Step 2 --> <!-- Workflow and other relevant labels # ~"group::" ~"Category:" ~"GitLab Ultimate" Other settings you might want to include when creating the issue. # /assign @ # /epic & --> ## Verification steps <!-- Add verification steps to help GitLab team members test the implementation. This is particularly useful during the MR review and the ~"workflow::verification" step. You may not know exactly what the verification steps should be during issue refinement, so you can always come back later to add them. 1. Check-out the corresponding branch 1. ... 1. Profit! -->