Different ECDSA keys check as identical during LDAP sync

[johnstonjs]

• Gitea version (or commit ref): 1.13.2
• Git version: 2.25.1
• Operating system: Linux (Ubuntu 20.04), downloaded amd64 binary from gitea GitHub, run from systemd
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No (arguably N/A)
• Log gist:

2021/02/04 06:19:14 models/user.go:1622:addLdapSSHPublicKeys() [E] addLdapSSHPublicKeys[MySite LDAP]: Error adding LDAP Public SSH Key for user user_name: public key already exists [owner_id: 2, name: MySite LDAP-ecdsa-sha2-nistp521 first_20_chars_of_ecdsa_key]

Description

Gitea appears to only check the first few characters of SSH keys during LDAP import to determine whether they are identical.

While updating from RSA keys to ECDSA keys generated by OpenSSH, I noticed that only one key would be loaded by Gitea into my user profile from LDAP. Generating the keys within a few minutes of each other on multiple systems, the first 20-30 characters of each are identical. The log file (relevant section quoted above) declares that the keys "already exist" and provides the same first 20 characters of each key. These are 521 bit ECDSA keys generated by OpenSSH's ssh-keygen on different systems, and are not identical.

Steps to reproduce:
Use Gitea with an LDAP source for SSH keys
Generate more than one ECDSA key using ssh-keygen and load into LDAP
Synchronize external data sources and check log file.

The similarity of the first 20-30 characters of each key may well be a separate issue for OpenSSH. Every time I generate an ECDSA key it has the same 20-30 characters as the ECDSA key shown in (5092).

Looking at a previous issue relating to ECDSA keys (5092), is the parsing function in the fix comparing the complete keys?

Thank for considering this issue, and please advise if there's anything else I can do to help troubleshoot/resolve.

[zeripath]

This will have been fixed by #13989