* E.g. look up in in [verify/.sops.yaml](verify/.sops.yaml)
## 1a. Onboarding: [New User]: create and add a gpg key
- create a branch titled `add_pubkey_<firstname>-<lastname>`
- e.g. `git branch add_pubkey_test-user`
- create a branch titled `add_pubkey_<firstname>-<lastname>`<!-- Review from Bas: Please make sure it's clear to the user that you mean this repo. -->
- e.g. `git branch add_pubkey_test-user`<!-- Review from Bas: The "e.g." is a bit confusing to me. Did you mean "i.e." instead? I'm OK if you leave the "e.g." out. -->
- Note: no strict naming convention for the branch, it's strictly a Human-in-the-Loop process
- please follow steps 1-13 at the following link: https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key
- CAVEAT: step 14 is not necessary, as it is specific to a GitHub account
@ -22,7 +22,7 @@ Roles:
- file format: `<email>@netgo.de.gpg.pub`
- git: commit the new file, push
- open a MergeRequest/PullRequest
- hand-off to an Existing User of the repo.
- hand-off to an Existing User of the repo. <!-- Review from Bas: Please re-write this part to be self-service only. E.g. "Before you begin: please make sure you know exactly which groups you need to have access to." -->
## 1b. Onboarding: [Existing User|New User]: Add new user to groups
@ -35,7 +35,7 @@ cd groups/<project_name>
ln -s ../../<path_to_key.gpg.pub>
```
Note: this step can be performed by anyone (either new user or existing user), but it makes the most sense for an existing user to configure the groups since this is domain-specific knowledge (i.e. new users won't typically know the grups)
Note: this step can be performed by anyone (either new user or existing user), but it makes the most sense for an existing user to configure the groups since this is domain-specific knowledge (i.e. new users won't typically know the grups)<!-- Review from Bas: -->
Lee Watson
10 months ago