### Summary My ssh-signed commits are marked as "Unverified" in the UI. I think this may be different than https://gitlab.com/gitlab-org/gitlab/-/issues/426065. ### Steps to reproduce In my `.git/config`, I have the relevant `[user]` block: ``` [user] name = Bill Evans email = MyEmail@MyCompany.com signingkey = ssh-rsa AAAAB3NzaC1yc2... ``` For local verification, I have the following in `~/.ssh/allowed_signers`, and have configured git with `git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers`: ``` MyEmail@MyCompany.com namespaces="git" ssh-rsa AAAAB3NzaC1yc2... ``` On the command line, `git log --show-signature` shows that the signatures are valid: ``` $ git log --show-signature commit 31dd8e1ffdc9d872a08f97fe031ba348b23edec4 (HEAD -> main, origin/main, origin/HEAD) Good "git" signature for MyEmail@MyCompany.com with RSA key SHA256:Gp3aF6QL8NuSDLj0as8TqhASyLrsPeYlXCJF1+wmPi8 Author: Bill Evans <MyEmail@MyCompany.com> ``` In my self-managed gitlab instance, my email is verified as lower-case, `myemail@mycompany.com`.  And the ssh key is configured, valid, not expired, not revoked, and is 4096 bits:  The UI shows that commit as unverified:  The only part of the puzzle that I can find that is different is that the email address on my self-managed gitlab instance is all lowercase, while the email associated with the signatures is PascalCase, but case-insensitive they are the same. I have been using the PascalCase email in my commits for a long time (and only started ssh-signing recently), I would very much like to not change the email address in the commits, if possible. I tried adding the PascalCase email to my account but it says (correctly) that the email is already taken and verified. ### What is the current *bug* behavior? "Unverified", perhaps because the case of the email address is different. ### What is the expected *correct* behavior? "Verified" signed commits. #### Results of GitLab environment info <!-- Input any relevant GitLab environment information if needed. --> <details> <summary>Expand for output related to GitLab environment info</summary> <pre> System information System: Current User: git Using RVM: no Ruby Version: 3.2.5 Gem Version: 3.6.5 Bundler Version:2.6.5 Rake Version: 13.0.6 Redis Version: 7.0.15 Sidekiq Version:7.2.4 Go Version: unknown GitLab information Version: 17.10.3 Revision: 22d4014a923 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 16.8 URL: https://mycompany.com/git HTTP Clone URL: https://mycompany.com/git/some-group/some-project.git SSH Clone URL: ssh://git@mycompany.com:20027/some-group/some-project.git Using LDAP: yes Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 14.41.0 Repository storages: - default: unix:/var/opt/gitlab/gitaly/gitaly.socket GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Gitaly - default Address: unix:/var/opt/gitlab/gitaly/gitaly.socket - default Version: 17.10.3 - default Git Version: 2.48.1.gl1 </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> Checking GitLab subtasks ... Checking GitLab Shell ... GitLab Shell: ... GitLab Shell version >= 14.41.0 ? ... OK (14.41.0) Running /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful Checking GitLab Shell ... Finished Checking Gitaly ... Gitaly: ... default ... OK Checking Gitaly ... Finished Checking Sidekiq ... Sidekiq: ... Running? ... yes Number of Sidekiq processes (cluster/worker) ... 1/1 Checking Sidekiq ... Finished Checking Incoming Email ... Incoming Email: ... Checking Reply by email ... IMAP server credentials are correct? ... Checking git@MyCompany.com no Try fixing it: An error occurred: Net::IMAP::NoResponseError: LOGIN failed. Check that the information in config/gitlab.yml is correct For more information see: doc/administration/reply_by_email.md Please fix the error above and rerun the checks. Mailroom enabled? ... skipped MailRoom running? ... skipped Checking Reply by email ... Finished Checking Incoming Email ... Finished Checking LDAP ... LDAP: ... Server: ldapmain LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 12 users of 100 limit. Checking LDAP ... Finished Checking GitLab App ... Database config exists? ... yes Tables are truncated? ... skipped All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Cable config exists? ... yes Resque config exists? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... yes Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units) Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units) Projects have namespace: ... 5/3 ... yes 4/4 ... yes 5/5 ... yes 5/6 ... yes 14/7 ... yes 4/9 ... yes 5/10 ... yes 4/12 ... yes 4/13 ... yes 4/14 ... yes 4/15 ... yes 4/16 ... yes 22/17 ... yes 22/18 ... yes 4/19 ... yes 22/20 ... yes 4/21 ... yes 4/22 ... yes 4/23 ... yes 4/24 ... yes 4/25 ... yes 4/26 ... yes 4/27 ... yes 3/28 ... yes 3/29 ... yes 3/30 ... yes 3/31 ... yes 3/32 ... yes 3/33 ... yes 3/34 ... yes 15/35 ... yes 15/36 ... yes 15/37 ... yes 15/38 ... yes 4/39 ... yes 2/40 ... yes 4/41 ... yes 4/42 ... yes 4/43 ... yes 15/44 ... yes 15/45 ... yes 5/46 ... yes 15/47 ... yes 15/48 ... yes 15/49 ... yes 14/50 ... yes 4/51 ... yes 15/52 ... yes 15/53 ... yes 4/54 ... yes 15/55 ... yes 14/56 ... yes 15/57 ... yes 15/58 ... yes 15/60 ... yes 4/61 ... yes 15/62 ... yes 15/63 ... yes 15/65 ... yes 15/66 ... yes 15/67 ... yes 15/68 ... yes 15/69 ... yes 4/71 ... yes 15/72 ... yes 5/73 ... yes 4/74 ... yes 15/75 ... yes 2/76 ... yes 15/77 ... yes 15/78 ... yes 15/79 ... yes 5/80 ... yes 15/82 ... yes 15/83 ... yes 15/84 ... yes 125/85 ... yes 15/86 ... yes 15/87 ... yes 15/88 ... yes 14/89 ... yes 15/90 ... yes 15/91 ... yes 15/92 ... yes 15/93 ... yes 15/94 ... yes 15/95 ... yes 15/96 ... yes 15/97 ... yes 15/98 ... yes 15/99 ... yes 15/100 ... yes 5/101 ... yes 5/102 ... yes 15/103 ... yes 15/104 ... yes 15/105 ... yes 15/106 ... yes 15/107 ... yes 15/108 ... yes 15/109 ... yes 15/110 ... yes 15/111 ... yes 131/112 ... yes 15/113 ... yes 14/114 ... yes 15/115 ... yes 15/116 ... yes 131/117 ... yes 131/118 ... yes 15/119 ... yes 131/120 ... yes 15/121 ... yes 15/122 ... yes 15/123 ... yes Redis version >= 6.2.14? ... yes Ruby version >= 3.0.6 ? ... yes (3.2.5) Git user has default SSH configuration? ... yes Active users: ... 10 Is authorized keys file accessible? ... yes GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes Checking GitLab App ... Finished Checking GitLab subtasks ... Finished </pre> </details> ### Possible fixes In gitlab: - allow case-insensitive comparison of email addresses for ssh-signatures, just like there is a case-insens search for existing email addresses In my config, not sure if this is "good" or has risk: - (risky) delete my verified email in my gitlab instance and resubmit the PascalCase version; I don't know if GL will "remember" the verified emails and not let me add it back in - (not preferred) change my git email address to all lowercase <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->