| ... | ... | @@ -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
|
|
|
|
[put it](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/81#note_2732337):
|
|
|
|
|
|
|
|
> I'm proposing that, since this is an area where the developers would
|
|
|
|
> need to shoulder most of the burden, the development teams should be
|
|
|
|
> responsible for coming up with solutions that work for them on some
|
|
|
|
> reasonable timeframe, and that this shouldn't be admin's problem
|
|
|
|
> assuming that the timeframe is long enough.
|
|
|
|
|
|
|
|
For now, the result of that discussion is a [summary of git repository
|
|
|
|
integrity solutions](howto/gitlab#git-repository-integrity-solutions), which is therefore delegated to teams.
|
|
|
|
|
|
|
|
### Migration roadmap
|
|
|
|
|
|
|
|
TODO. |
