Don't take fingerprints for the internal authorized_keys API
gitlab-shell-authorized-keys does a GET request against the internal API to learn whether a given SSH key is known to GitLab and, if so, what user it is attached to. This is used to validate SSH sessions. For a very long time, gitlab-shell has sent only the full base64 encoded public key, from which we derive a fingerprint for looking up the key on the GitLab side. However, the API does have legacy support for gitlab-shell sending just the key fingerprint. It has not been used in gitlab-shell since March 2016. We want to update GitLab so it derives the SHA256 fingerprint for the search, rather than the MD5 fingerpring. Doing this is made easier if we remove the `fingerprint` parameter and only accept `key` in the API endpoint. This is safe to do, because `fingerprint` is unused, and does not break any compatibility guarantees since the internal API is not bound by the v4 REST API compatibility promise. The documentation does not refer to the `fingerprint` parameter at all, and doing this in 14.0 should means that we don't have to think about zero-downtime compatibility either, although that should also be fine. Changelog: removed
Showing
Please register or sign in to comment