@@ -385,3 +385,76 @@ and only gitolite configuration restricts further access.
Access to push to this repository is controlled by the
`gitolite-admin` repository entry in the gitolite configuration file,
and not by LDAP groups.
## GitLab migration
As mentioned in the lead, the gitolite/gitweb infrastructure is, as of
May 2021, considered *legacy* and users are encouraged to create new
repositories, and migrate old ones to GitLab. In the intermediate
period, repositories can be [mirrored between gitolite and GitLab](#github-and-gitlab-mirrors)
as well.
### Security concerns
> This section is a summary of the discussions that happened in [tpo/tpa/gitlab#36](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/36) and [tpo/tpa/gitlab#81](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/81).
Some developers expressed concerns about using GitLab as a canonical
location for source code repositories, mainly because of the much
broader attack surface GitLab provides, compared to the legacy,
[gitolite-based infrastructure](howto/git), especially considering that the
web application basically has write access to everything.
Of course, GitLab is larger, and if there's an unauthenticated attack
against GitLab, that could compromise our respositories. And there is
a stead flow of new [vulnerabilities in GitLab](https://www.cvedetails.com/vulnerability-list/vendor_id-13074/Gitlab.html)([sorted by
priority](https://www.cvedetails.com/vulnerability-list.php?vendor_id=13074&product_id=&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=178&sha=fe38ca18c40b857201e9ae9283dea03b71b724f0)), including remote code execution. And although none of
those provide *unauthenticated* code execution, our anonymous portal
provides a bypass to that protection, so this is a real threat that
must be addressed.
When we think about authenticated users, however, gitolite has a
problem: our current gitolite install is pretty old, and
(deliberately) does not follow new upstream releases. Great care has
been taken to run a gitolite version that is specifically older, to
ensure a smaller attack surface, because it has less features than
newer gitolite versions. That's why it's such a weird version.
It is worrisome that we use an old version of the software that is
essentially unmaintained. It is technical debt that makes maintenance
harder. It's true that this old gitolite has a much smalller attack
surface than gitlab (or even more recent gitolite), but the chosen
approach to fix this problem has to do with having other mechanisms to
ensure code integrity (code signing and supply chain integrity) or
secrecy (ie. encrypted repositories) than trusting the transport.
We are actively maintaining gitlab, following upstream releases quite
closely. Upstream is actively auditing their code base, and many
vulnerabilities published are actually a result of those internal
audits.
If we are worried about trust in our supply chain, GitLab security is
only part of the problem. It's a problem that currently exists with
Gitolite. For example, what happens if a developer's laptop gets
compromised? How do we audit changes to gitolite repositories,
assuming it's not compromised? GitLab provides actually more
possibilities for such audits. Solutions like code reviews, signed
commits, reproducible builds, and transparency logs provide better,
long-term and service-agnostic solutions to those problems.
In the end, it came up to a trade-off: GitLab is much easier to
use. Convenience won over hardened security, especially considering
the cost of running two services in parallel. Or, as Nick Mathewson
