summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorIkiWiki <ikiwiki.info>2020-10-22 07:11:14 +0000
committerIkiWiki <ikiwiki.info>2020-10-22 07:11:14 +0000
commit9caf1c725d1c91269d9ea3a9193fa1a647b86ba2 (patch)
tree253f13391ffffdc7244eb8644cf2f8975affa1a6
parent8a19b33e1e6dc10fb8e0f20e269f28466c4e8143 (diff)
parenta71ffddbcd7eeb862b3ff8ce6d55ff333308e536 (diff)
Merge branch 'master' of gitlab-ssh.tails.boum.org:tails/tails
-rw-r--r--wiki/src/contribute/working_together/GitLab.mdwn122
-rw-r--r--wiki/src/contribute/working_together/roles/sysadmins.mdwn3
-rw-r--r--wiki/src/contribute/working_together/roles/sysadmins/GitLab.mdwn167
3 files changed, 181 insertions, 111 deletions
diff --git a/wiki/src/contribute/working_together/GitLab.mdwn b/wiki/src/contribute/working_together/GitLab.mdwn
index 835644d..c87983c 100644
--- a/wiki/src/contribute/working_together/GitLab.mdwn
+++ b/wiki/src/contribute/working_together/GitLab.mdwn
@@ -432,118 +432,13 @@ first, to ensure you're not asking them to do something that's outside
of the scope of their job. And please justify your suggestions.
Please check these views once in a while and talk to us! :)
-<a id="operations"></a>
-
-# Operations
-
-## Administration of GitLab
-
-Our friends at <https://www.immerda.ch/> host [[!tails_gitlab desc="our GitLab
-instance"]].
-
-The Tails [[system administrators|working_together/roles/sysadmins]]
-administrate this GitLab instance.
-
-## Configuration of GitLab
-
-The configuration of our GitLab instance lives in the private [[!tails_gitlab
-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 [[!tails_gitlab groups/tails/-/labels desc="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
-
<a id="access-control"></a>
-## Access control
-
-### Objects
-
- - _Canonical Git repo_: the authoritative [[!tails_gitlab tails/tails]]
- repository, hosted on GitLab
-
- - _Major branches_: `master`, `stable`, `testing`, `devel`,
- and possibly `feature/bullseye`
-
- - _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.<br/>
- This was already a problem with Redmine.<br/>
- 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;<br/>
- 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_gitlab 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;<br/>
- 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_gitlab 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_gitlab 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
+# Access control
<a id="request-access"></a>
-#### Requesting access
+## Requesting access
If you need to do something in GitLab and you appear to lack the
needed credentials, please ask the Tails
@@ -553,7 +448,7 @@ to grant you more power.
For example, you will need "Reporter" access on the [[!tails_gitlab
tails/tails]] project in order to add labels or assign issues.
-#### Adding/removing access
+## Adding/removing access
Do not grant access via the web interface:
@@ -565,14 +460,14 @@ Instead, after following the relevant process (if any),
request the access modification from the Tails
[[system administrators|working_together/roles/sysadmins#communication]].
-#### Relevant GitLab doc
+## Relevant GitLab doc
- [[!tails_gitlab help/user/permissions.html desc="Permissions"]]
- [[!tails_gitlab help/user/project/merge_requests/authorization_for_merge_requests.html desc="Authorization for Merge requests"]]
- [[!tails_gitlab help/user/project/protected_branches.html desc="Protected Branches"]]
- [[!tails_gitlab help/user/group/index.md desc="Groups"]]
-#### Access levels
+## Access levels
We use the [[!tails_gitlab
help/user/project/merge_requests/authorization_for_merge_requests.html#protected-branch-flow
@@ -588,3 +483,10 @@ desc="Protected branch flow"]]:
They push topic branches to their own fork of the repository and
create merge requests.
- Our Jenkins CI jobs generation process is the same as in pre-GitLab days.
+
+<a id="operations"></a>
+
+# Operations
+
+See our documentation about [[GitLab for Tails
+sysadmins|contribute/working_together/roles/sysadmins/GitLab]].
diff --git a/wiki/src/contribute/working_together/roles/sysadmins.mdwn b/wiki/src/contribute/working_together/roles/sysadmins.mdwn
index d1f87b4..430e2f1 100644
--- a/wiki/src/contribute/working_together/roles/sysadmins.mdwn
+++ b/wiki/src/contribute/working_together/roles/sysadmins.mdwn
@@ -239,7 +239,7 @@ Below, importance level is evaluated based on:
- host Tails issues
- host most Tails [[Git repositories|contribute/git]]
* access: public + some data with more restricted access
-* operations documentation: [[contribute/working_together/GitLab#operations]]
+* operations documentation: [[contribute/working_together/roles/sysadmins/GitLab]]
* end-user documentation: [[contribute/working_together/GitLab]]
* configuration:
- immerda hosts our GitLab instance using [this Puppet
@@ -251,6 +251,7 @@ Below, importance level is evaluated based on:
- configuration: [[!tails_gitlab tails/gitlab-config]]
* importance: critical (needed to release Tails)
* Tails system administrators administrate this GitLab instance.
+* See our [[documentation about GitLab for Tails sysadmins|contribute/working_together/roles/sysadmins/GitLab]].
## Gitolite
diff --git a/wiki/src/contribute/working_together/roles/sysadmins/GitLab.mdwn b/wiki/src/contribute/working_together/roles/sysadmins/GitLab.mdwn
new file mode 100644
index 0000000..bf08d51
--- /dev/null
+++ b/wiki/src/contribute/working_together/roles/sysadmins/GitLab.mdwn
@@ -0,0 +1,167 @@
+[[!meta title="GitLab for Tails sysadmins"]]
+
+[[!toc levels=2]]
+
+This page documents what Tails syadmins need to know about our GitLab instance.
+The user documentation is kept [[in a separate
+page|contribute/working_together/GitLab]].
+
+Tails previously used Redmine, and the migration was coordinated using
+[[Salsa|https://salsa.debian.org/tails-team/gitlab-migration]].
+
+# Administration of GitLab
+
+Our friends at <https://www.immerda.ch/> host [[!tails_gitlab desc="our GitLab
+instance"]]. We usually contact them through e-mail or their Jabber channel
+(see their [[contact info|https://www.immerda.ch/contact.html]]).
+
+The Tails [[system administrators|working_together/roles/sysadmins]]
+administrate this GitLab instance. They don't have shell access to the VM
+hosting the service so, among many other things, using [[Server
+Hooks|https://docs.gitlab.com/ce/administration/server_hooks.html]] 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
+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 [[!tails_gitlab groups/tails/-/labels desc="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.
+
+<a id="access-control"></a>
+
+# Access control
+
+## Objects
+
+ - _Canonical Git repo_: the authoritative [[!tails_gitlab tails/tails]]
+ repository, hosted on GitLab
+
+ - _Major branches_: `master`, `stable`, `testing`, `devel`,
+ and possibly `feature/bullseye`
+
+ - _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.<br/>
+ This was already a problem with Redmine.<br/>
+ 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;<br/>
+ 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_gitlab 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;<br/>
+ 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_gitlab 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_gitlab 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 [[contribute/working_together/GitLab#access-control]].
+
+# Interactions with other parts of our infrastructure
+
+The following pieces of the Tails infrastructure interact with GitLab either
+directly or indirectly:
+
+ - The [[Ticket Gardener|contribute/working_together/roles/ticket_gardener]]
+ queries GitLab for information about the state of issues and merge
+ requests.
+
+ - The [[Translation
+ Platform|contribute/working_together/roles/translation_platform]]
+ constantly merges modifications made through
+ [[Weblate|https://translate.tails.boum.org]] and pushes them back to the Tails
+ main repository (see [[the
+ script|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/weblate/scripts/cron.sh]]
+ for that). We use a local "gatekeeper" repository with a
+ [[hook|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/gitolite/hooks/tails-weblate-update.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|https://gitlab.tails.boum.org/tails/tails]] 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|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/gitolite/hooks/www_website_ping-post-update.hook]]
+ Ikiwiki when its master branch was modified. Some other [["underlay"
+ repositories|https://gitlab.tails.boum.org/tails/puppet-tails/tree/master/manifests/website.pp#n19]]
+ are also configured to [[cause Ikiwiki to
+ refresh|https://gitlab.tails.boum.org/tails/puppet-tails/tree/master/files/gitolite/hooks/www_website_underlays-post-update.hook]]
+ the main website.
+
+ - Our [[Jenkins|contribute/working_together/roles/sysadmins/Jenkins]] master
+ [[is also
+ notified|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/templates/gitolite/hooks/tails-post-receive.erb]]
+ when there are relevant changes to the main Tails repository, and its Jenkins
+ slaves query GitLab to determine [[whether to conduct reproducibility
+ tests|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/jenkins/slaves/isobuilders/decide_if_reproduce]]
+ and [[whether to send notifications through
+ e-mail|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/jenkins/slaves/isobuilders/output_ISO_builds_and_tests_notifications]].