- contribute
- working together
- roles
- sysadmins
- GitLab for Tails sysadmins
This page documents what Tails syadmins need to know about our GitLab instance. The user documentation is kept in a separate page.
Tails previously used Redmine, and the migration was coordinated using Salsa.
Administration of GitLab
Our friends at https://www.immerda.ch/ host our GitLab instance. We usually contact them through e-mail or their Jabber channel (see their contact info).
The Tails system administrators administrate this GitLab instance. They don't have shell access to the VM hosting the service so, among many other things, using Server Hooks is not easy and would depend on coordination with the service provider.
Configuration of GitLab
The configuration of our GitLab instance lives in the private tails/gitlab-config GitLab project.
If you have access to this project, you can propose configuration changes: push a topic branch and submit a merge request.
This can be useful, for example:
to modify group membership when someone joins or leaves a team
to propose new group labels shared by all our GitLab projects
to propose a new project under the
tails/
namespace, ensuring our common project settings & permission model are applied
Note that GitLab's root
user is an owner of all projects because that makes
sense for the way Tails currently manages user permissions for the different
groups and projects. Notifications are turned off for that user and it
shouldn't be used for communicating with other users.
Access control
Objects
Canonical Git repo: the authoritative tails/tails repository, hosted on GitLab
Major branches:
master
,stable
,testing
,devel
Release tags: a signed Git tag that identifies the source code used to build a specific Tails release; currently all tags in the authoritative
tails.git
repository are release tags; the tag name is a version number, with '~' replaced by '-'.Particularly sensitive data: confidential data that specific teams like Fundraising and Accounting need to handle, but that other contributors generally don't need direct access to. This definitely include issues; this might include Git repositories at some point.
Note that as of 2020-03-29, it is undefined:
What subset of this data can go to a web-based issue tracker or not.
This was already a problem with Redmine.
Fixing this will require discussions between various stakeholders.What subset of this data could live in a cleartext Git repository hosted here or there, as opposed to requiring end-to-end encryption between members of these teams. This is a hypothetical problem for now.
Subjects
An admin:
can configure GitLab
As a consequence, an admin can grant themselves any permission they want if an emergency requires it; in other situations, better follow due process to request such status or permissions :)
MUST comply with our "Level 3" security policy
A committer:
can push and force-push to any ref in the canonical Git repo, including major branches and release tags;
incidentally, this ensures the following requirement is met:their branches are picked up by Jenkins; it follows that they MUST comply with our "Infrastructure" security policy
can merge MRs into major branches
can modify issues metadata
is allowed to view confidential issues in the tails/tails GitLab project; that's OK, because particularly sensitive data lives somewhere else, with stricter access control
can edit other users' comments
MUST comply with our "Level 3" security policy
A regular, particularly trusted contributor:
can push and force-push to a subset of refs in the canonical Git repo; this subset MUST NOT include any major branch nor release tag;
this is required to ensure the following requirement is met:their branches are picked up by Jenkins; it follows that they MUST comply with our "Infrastructure" security policy
can modify issues metadata
is allowed to view confidential issues in the tails/tails GitLab project; that's OK, because particularly sensitive data lives somewhere else, with stricter access control
A regular contributor:
can fork the Git repositories and push changes to their own fork
can modify issues metadata
is allowed to view confidential issues in the tails/tails GitLab project; that's OK, because particularly sensitive data lives somewhere else, with stricter access control
Anybody with a GitLab account on the instance we use:
can view and submit issues in public projects
can submit MRs in public projects
Implementation
See GitLab.
Interactions with other parts of our infrastructure
The following pieces of the Tails infrastructure interact with GitLab either directly or indirectly:
The Ticket Gardener queries GitLab for information about the state of issues and merge requests.
The Translation Platform constantly merges modifications made through Weblate and pushes them back to the Tails main repository (see the script for that). We use a local "gatekeeper" repository with a hook to prevent the Translation Platform from messing with more things than it should.
Ikiwiki is notified whenever there's a change in the
master
branch of the main Tails repository and creates/updates.po
files when new content was added to the Tails website. For this, GitLab was manually configured to mirror the main Tails repository to a local repository in the Tails infrastructure, and the local mirror pings Ikiwiki when its master branch was modified. Some other "underlay" repositories are also configured to cause Ikiwiki to refresh the main website.Our Jenkins master is also notified when there are relevant changes to the main Tails repository, and its Jenkins slaves query GitLab to determine whether to conduct reproducibility tests and whether to send notifications through e-mail.