Add gitlab.com ssh host keys as builtin

[est31]

PR #11556 has added github.com ssh host keys as builtin. This adds gitlab.com ssh host keys.

The "unknown SSH host key" error is quite annoying as, unlike ssh, it does not allow you to press y and continue. Instead you are asked to manually edit config files.

I've tested it locally and I've confirmed both the error with latest master, as well as that the builtin key works with this PR applied.

The keys can be found in this URL.

r? @ehuss

[weihanglo]

Looks good to me. Thanks!

Just some questions and ideas: Are there more vendors worth adding as built-in? I wonder How to draw a line between built-in and user opt-in. We've talked about introduce an interactive console but the time was limited as it was a CVE fix. I feel like we could explore more on this direction.

[est31]

@weihanglo you bring up good points!

I have only added gitlab in this PR because gitlab is probably the biggest git host after github, and I also have a gitlab account so I was able to test whether the keys work. If you want to join the rust-lang zulip, you are shown options to log in via four ways: a native zulip account, google, github, gitlab.

If one wants to make a more extensive list than the two, one could probably do some googling to find lists on the internet of the biggest git hosters. That would still be quite arbitrary but it would give a starting point. E.g. this list or this list.

I have checked the hosts from the union of the two lists for their host keys (plus source hut). Most of these only specify the fingerprints:

• bitbucket
• sourceforge
• AWS codecommit has separate keys for each AWS region...
• sourcehut
• Perforce, Azure Repos, Beanstalk, and Codebase don't specify their host keys at all.

The host keys can still be obtained however, by e.g. running ssh-keyscan -t rsa <hostname>.

Google maintains a hsts preload list as well as a list of websites with pinned tls CAs. Both lists are quite long, so there is precedent in having non-trivially short hardcoded lists. Of course however, maintenance of those lists requires an overhead.

Which brings us to the other point: probably such lists need to be kept up to date. SSH host keys don't change every day, but they probably still change every now and then. There should be some kind of automation to detect such changes. For two hosts github and gitlab we can probably get away with manual checking that these keys are up to date, but more niche hosts might not even have one user, so we might ship wrong keys for years until we notice problems. The most automatable way to obtain the keys would probably be to run ssh-keyscan in regular intervals, as the ssh keys are not exposed in a machine readable format (unless we want to start parsing the html, which might not be that hard if we look for key phrases like ssh-rsa or such).

[est31]

IMO it should be quite uncontroversial to add gitlab, we can discuss these other questions (automation, which other hosts to add) orthogonally from having this PR merged.

[weihanglo]

Thank you for your analysis and inputs! I am totally fine with adding GitLab. Let's wait for others opinions :)

[ehuss]

Nominating for further discussion.

[joshtriplett]

We discussed this in today's @rust-lang/cargo meeting.

The only reason we include the github.com SSH key is because we currently get the crates.io index from github, and sometimes people use insteadOf in their git configurations to use SSH for github. (People shouldn't do that, and should instead use pushInsteadOf, but nonetheless this is common and we don't want to break in those cases.)

Once we switch to sparse registries, we can consider dropping even the github SSH key.

[est31]

The only reason we include the github.com SSH key is because we currently get the crates.io index from github, and sometimes people use insteadOf in their git configurations to use SSH for github.

I don't really agree that this justification is enough. If someone edits their configuration and uses insteadOf, then they will have likely also connected to github.com via the git CLI before at least once.

Personally the main impact I see in the hardcoding of those SSH keys is a symbolic one. It's documented in high level documentation that cargo ships with github.com's keys.

This worsens an already existing problem. Already before #11556 , cargo/crates.io has been considering github alternatives way too little. E.g. to publish on crates.io you must have a github account. #11556 has made the problem even worse.

Having a close relationship to github for rust-the-oss-project (repo hosting, CI use, free index hosting, etc) is nice and totally fine, but it should not bleed into what Rust does facing towards its users as rust-the-technology. There should be a limit in the marketing value github.com gets from providing free cloud services to Rust. Having "Rust uses us" on their list should be enough, no need for having statements that amount to "Rust has made connecting to github.com especially easy" in the documentation. That's what rubs me wrong here.

Gitlab would have helped at least to some degree.

[Eh2406]

I don't really agree that this justification is enough. If someone edits their configuration and uses insteadOf, then they will have likely also connected to github.com via the git CLI before at least once.

I think that's a fairly convincing argument for removing github hard coded keys.

[joshtriplett]

I would very much like to see those keys removed, rather than adding more, yes. Let's plan on doing that as soon as we switch to https indexes by default.