Skip to content

Commit

Permalink
Flesh out steps for creating a new key, move to new section and add s…
Browse files Browse the repository at this point in the history
…ection for using a subkey of an existing key as per laminas#32

Signed-off-by: Carnage <[email protected]>
  • Loading branch information
carnage committed Dec 5, 2020
1 parent 6fc8768 commit b03e433
Showing 1 changed file with 37 additions and 8 deletions.
45 changes: 37 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,11 +28,6 @@ to your project or organization:
- `GIT_AUTHOR_EMAIL` - email address of the author of your releases: can be an email address of a bot account.
- `SIGNING_SECRET_KEY` - a **password-less** private GPG key in ASCII format, to be used for signing your releases:
please use a dedicated GPG subkey for this purpose. Unsigned releases are not supported, and won't be supported.
To generate a new GPG key use the following commands
`gpg2 --full-generate-key` Pick option 4, then type 4096 for key size, select your desired expiry. Fill out the user information and leave the password blank.
Once generated it will output something like `gpg: key <Key ID> marked as ultimately trusted` take a note of this Key Id to use in the next step
`gpg --output private.key --armor --export-secret-key <Key ID>` This will output the key to the file private.key in the correct format to paste into github. Delete the file once you are done and don't share it with anyone else
Optionally you can use `gpg --output public.key --armor --export <Key ID>` to export the corresponding public key. You can publish this key on your project webpage to allow users to verify your signed releases.
- `ORGANIZATION_ADMIN_TOKEN` - if you use the file from [`examples/.github/workflows/release-on-milestone-closed.yml`](examples/.github/workflows/release-on-milestone-closed.yml),
then you have to provide a `ORGANIZATION_ADMIN_TOKEN` (with a full repo scope), which is a github token with
administrative rights over your organization (issued by a user that has administrative rights over your project).
Expand All @@ -45,11 +40,45 @@ you when you enable GitHub Actions. To learn more about how it works, read
["Authenticating with the GITHUB\_TOKEN"](https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token)
in the GitHub Docs.

### Branches
### Setting up GPG keys

You will also need to setup the initial branches used by this project.
#### Using a subkey from an existing GPG key

@TODO
First open your master key for editing `gpg --edit-key "<YOUR MASTER KEY ID>"` type `addkey` and select signing or s for
capabilities. RSA key type is recommended for greatest compatibility. Type `save` to persist the new subkey to your
master key. Make a note of the Key ID as you will need it in the next step.

Next export the new sub key `gpg --output private.key --armor --export-secret-subkeys "<SubKey ID>!"` this will be exported to
the file private.key the ! at the end is important as it limits the export to just the sub key
**Delete the file once you are done and don't share it with anyone else**

If your master key is password protected, you will need to remove the password from the subkey before you can add it into
github settings, you can skip this if your master key is not password protected.

To remove the password from the subkey create a ephemeral gpg home directory `mkdir /tmp/gpg` and ensure that it works with gpg
`gpg --homedir /tmp/gpg --list-keys` You can ignore the warning about unsafe directory permissions.
Import your subkey `gpg --homedir /tmp/gpg --import private.key` and enter edit mode `gpg --homedir /tmp/gpg --edit-key <SubKey ID>`
type `passwd` entering your current password and then set the password to "" to remove it.
Type `save` to exit edit mode and reexport your subkey `gpg --homedir /tmp/gpg --output private.key --armor --export-secret-subkeys "<SubKey ID>!"`.
Finally, remove the ephemeral directory: `rm --rf /tmp/gpg`

You will now need to do `gpg --output public.key --armor --export <YOUR MASTER KEY ID>` to export your master public key
with the new subkey public key to the file `public.key`. Then republish it to anywhere that you currently publish your public keys

#### Using a new key

To generate a new GPG key use the following command `gpg2 --full-generate-key` Pick option 4, then type 4096 for key size, select your desired expiry.
Fill out the user information and leave the password blank.

Once generated it will output something like `gpg: key <Key ID> marked as ultimately trusted` take a note of this Key Id to use in the next step.

`gpg --output private.key --armor --export-secret-key <Key ID>` This will output the key to the file `private.key` in the correct format to put into the environment
variable required for setup. **Delete the file once you are done and don't share it with anyone else**

Optionally you can use `gpg --output public.key --armor --export <Key ID>` to export the corresponding public key to the file `public.key`.
You can publish this key on your project webpage to allow users to verify your signed releases.

You could sign this new key with your personal key and the keys of other project maintainers to establish its provenance.

## Usage

Expand Down

0 comments on commit b03e433

Please sign in to comment.