Previously the task for creating an issue in archlinux-keyring to remove
a main key was bundled together with the similar task for packager keys.

Also introduce a task for removing the @master-key.archlinux.org email.

The format of the keyring issue creation tasks was modified in commit
d47c558c ("Improve .gitlab/issue_templates/Offboarding.md").

- Link to referenced files in the git repo.
- Use new issue URLs that preselect the issue template.
- Add dev and TU private IRC channels.

Fixes: 2c69e12d ("Extend onboarding information for signing keys")

We have offered a arch mail address, for support staff, for over a
year[1][2] and the only difference, is that support staff must only be
granted SSH access to mail.archlinux.org. SSH access to
homedir.archlinux.org is also allowed, but it is opt-in[3].

[1] 7287d6d3 ("archroles: Add support-staff group")
[2] 50c3e0f9 ("archusers: Support restricting users to specific hosts")
[3] e0e52552 ("Allow Alad access to homedir.archlinux.org")

Fix #372

Since [1][2].

[1] gluebuddy@8a105288
[2] !524

[1] https://lists.archlinux.org/archives/list/staff@lists.archlinux.org/thread/3LFY3OVV4MHXR2WTYDFS6EWNATGFCE3E/

Reaching out to the user is cumbersome, especially if the user is being
offboarded due to inactivity.

Fixes: bb000824 ("mailman: Second batch of mailman3 migrated lists")

There is no need to run all playbooks for this.

The idea bebind this is to be able to give vault access to new DevOps
members without giving away more important credentials like Hetzner's.

Kristian Klausen authored 3 years ago and Jelle van der Waa committed 3 years ago

We are usually setting up forwarding when offboarding, so it should be
documented, also we shouldn't keep the forwards around forever.

- Link to referenced files in the git repo.
- Use new issue URLs that preselect the issue template.

Only run it for te required playbooks, exclude the phrik playbook as we
only need it to give demize access to phrik and only running archusers
removes demize from the phrik group. Seperate bug which should be
fixed...

github-pull-closer[1] needs write access for closing the PRs.

[1] https://gitlab.archlinux.org/archlinux/github-pull-closer/

Fix #390

Fix #386

Be more explicit about selecting allowed repos because these were missed
in previous onboardings.

.gitlab/issue_templates/Onboarding.md:
Create the ticket as confidential by default (using a short action).
Make the required information in the Details section more explicit and
add entries that are relevant when creating an SSO and/or archweb
account.
Add a note for sponsors of new users, so that they also add a
clearsigned version of the data they provide.
Add a dot at the end of each sentence.
Make the entries for mailing list operations more generic and rely on
the *communication e-mail address*, which may be the user's personal
mail address or a newly created @archlinux.org mail address.
Add warning message about creating a confidential ticket when providing
personal data.
Add checkbox to remind about the removal of personal information,
removal of description history and setting the ticket to be
non-confidential (if it has been confidential due to personal data).
Add checkbox that reminds setting the Team member username to the
@-prefixed username on gitlab (after the user has logged in).

Fix #80

Kristian Klausen authored 3 years ago and Jelle van der Waa committed 3 years ago

[1] https://archlinux.org/news/move-of-official-irc-channels-to-liberachat/

.gitlab/issue_templates/Onboarding.md:
Extend the information for onboarding of packager signing keys and new
main signing keys, including comments on who is supposed to create the
tickets towards the archlinux-keyring project.

.gitlab/issue_templates/Offboarding.md:
Add more specific information for developer offboarding (e.g. also
remove from arch-dev mailing list).
Add more specific information on which templates to choose and where to
open a ticket for signing key removal.

implements #226

Levente Polyak authored 3 years ago and Jelle van der Waa committed 3 years ago

This shouldn't be possible as it may lead to accidentally allowing
external users to be added to a project.
We should only add members to a project or group on staff request to
devops.

Levente Polyak authored 4 years ago and Sven-Hendrik Haase committed 4 years ago

Strictly speaking this is not a devops duty, but I believe this is
currently the best place to ensure we won't ever forget to create a
keyring revocation ticket for an offboarded former staff.