evaluate mitigation strategies to work around GitLab's attack surface for git hosting

as part of the possible gitolite to GitLab migration work (discussed in #36 (moved)), one of the issues that came up is the relative security of gitolite vs GitLab. to quote @nickm:

I am concerned about the security here. I know that the gitolite installation is old and crufty, but the gitlab code-base is HUGE. For gitolite, as I understand it, you have to be able to make an ssh connection to the server before you can change anything in a repository. But in gitlab, it seems that the gitlab server has write access to all the repositories. That makes a much much bigger attack surface, unless I grievously misunderstand the architectures here.

My response to this was:

Of course, GitLab is larger, and if there's an unauthenticated attack against GitLab, that could compromise our respositories. And there has been vulnerabilities in GitLab before, for sure. But looking at that list sorted by priority, i cannot find an unauthenticated vulnerability after reviewing the top ten. And I do not remember such an issue being ever disclosed although it's theoretically possible...

So my concern with GitLab is not that unauthenticated users might hack at it, but more what authenticated, trusted users could do. And there, of course, there is a plethora of privilege escalation vulnerabilities that have been disclosed (and fixed!). And that's where, when you compare to gitolite, there is a problem: our current gitolite install is vulnerable to 4 such issues at least, and possibly more, partly because it's so old, but also partly because gitolite is less well-maintained.

We are actively maintaining gitlab, following upstream releases quite closely. And while I'm not super happy about the attack surface (nevermind the complexity of managing the thing underneath!), everything (and especially security) is made of tradeoffs. And in this case, my opinion is that we should go towards GitLab for code hosting, because it will facilitate code review workflows, which is a large part of securing a product...

Or to put it more succintly:

If we are worried about trust in our supply chain, we need to look elsewhere, because gitolite cannot be trusted in its current state. I would encourage all teams to start signing their commits and verifying cryptographic history when doing releases. Having reproducible builds is also part of the equation, of course.

This issue is a space to discuss those possible solutions. It applies mostly to GitLab but I would argue it also applies to the trust we put in gitolite as well (which I consider to be misplaced).