libgit2: check hostkey type when validating hostkey

[phillebaba]

This change adds checking for fingerprint types other than SHA1 when checking the hostkey. This is a bug which has not been an issue yet as very few git servers use MD5 fingerprints and Azure DevOps still uses SHA1 fingerprints. It could potentially be an issue when using the libgit2 implementation with GitHub as it uses SHA256 fingerprints.

[hiddeco]

This looks OK to me, but I am linking in @squaremo as a second pair of eyes given I have not been on my best on this topic the past days...

Thank you @phillebaba 🙏

[phillebaba]

@hiddeco is there a test that verifies libigit2 cloning over ssh? I can manually verify this if it needs to get merged tomorrow, but I will try to get a test in tonight.

[hiddeco]

@phillebaba the image controllers cover this indirectly, and confirmed my changes in #288 worked. I do however think that the matches method can be unit tested here, as we can simply mock the structure and arguments.

[squaremo]

hostkey.Kind is a bitset, so you want something like

switch {
    case hostkey.Kind & git2go.HostkeySHA256 > 0:
        ...
}

i.e., check the bitset against each enum value, starting with the most preferred (SHA256) down to the lowly MD5.

(if you print hostkey.Kind out, it'll usually have the value 7, which is HostkeyMD5 | HostkeySHA1 | HostkeySHA256 (the enum values are in https://github.com/libgit2/libgit2/blob/27e34f9b9843f7bcc33a4ccfe3e395fe303cba63/include/git2/cert.h#L76)

[squaremo]

My image-auto tests pass with this change, and running an automation against github.com with SSH/libgit2 also works.

[phillebaba]

I am just going to add a test to verify priority and then we can merge this.

[hiddeco]

Given it has now test coverage on top of the tests performed by Michael, and the unit tests for the commit that added them passed, I am confident this works.

Thank you for following up @phillebaba 🥇