Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: add runc.keyring file #3824

Merged
merged 5 commits into from
Apr 19, 2023
Merged

release: add runc.keyring file #3824

merged 5 commits into from
Apr 19, 2023

Conversation

cyphar
Copy link
Member

@cyphar cyphar commented Apr 11, 2023

In order to allow any of the maintainers to cut releases for runc,
create a keyring file that distributions can use to verify that releases
are signed by one of the maintainers.

The format matches the gpg-offline format used by openSUSE packaging,
but it can be easily imported with gpg --import so any distribution
should be able to handle this keyring format wtihout issues.

Each key includes the GitHub handle of the associated user, and a new
verification step is added to CI to ensure that the key is actually one
of the keys the user has registered with GitHub (as well as being a
maintainer).

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

@cyphar cyphar added the backport/1.1-todo A PR in main branch which needs to be backported to release-1.1 label Apr 11, 2023
@cyphar cyphar added this to the 1.2.0 milestone Apr 11, 2023
@cyphar
Copy link
Member Author

cyphar commented Apr 11, 2023

Unfortunately it looks like you cannot give actions write access using GITHUB_TOKEN from a pull request. The only way to get this to work would be to create a personal access token to store as a secret, but unfortunately I cannot create a scoped one for opencontainers (I could create a classic personal access token for myself but those aren't scoped).

(It's also a bit ugly that trstringer/manual-approval creates a new issue. Ideally it would all be contained in this pull request. Maybe we can fork manual-approval for this purpose? Idk.)

All of the other logic works, so maybe we can just get the core bits in and then work on a GHA setup later?

In order to allow any of the maintainers to cut releases for runc,
create a keyring file that distributions can use to verify that releases
are signed by one of the maintainers.

The format matches the gpg-offline format used by openSUSE packaging,
but it can be easily imported with "gpg --import" so any distribution
should be able to handle this keyring format wtihout issues.

Each key includes the GitHub handle of the associated user. There isn't
any way for this information to be automatically verified (outside of
using something like keybase.io) but since all changes of this file need
to be approved by maintainers this is okay for now.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
@cyphar cyphar marked this pull request as ready for review April 19, 2023 02:59
@cyphar
Copy link
Member Author

cyphar commented Apr 19, 2023

I've dropped the special review system (arguably it doesn't match the governance rules of runc anyway). Instead, we now have a validation step which ensures that each key in runc.keyring actually matches the publicly-listed GPG keys of the specified GitHub user (and that the user is actually a maintainer in MAINTAINERS).

Note that if you wish to add your key to the keyring, you need to make sure that it was uploaded recently (otherwise GitHub won't list the key in https://github.com/username.gpg which means it will fail the validation checks) and it doesn't contain any subkeys not present in the GitHub version of the key.

cyphar and others added 4 commits April 19, 2023 13:48
We need to make sure the release is being signed by a key that is
actually listed as a trusted signing key, and we also need to ask the
person cutting the release whether the list of trusted keys is
acceptable.

Also add some verification checks after a release is signed to make sure
everything was signed with the correct keys.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
These checks ensure that all of the keys in the runc.keyring list are
actually the keys of the specified user and that the users themselves
are actually maintainers.

Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
keyid 5F36C6C61B5460124A75F5A69E18AA267DDB8DB4

This is the signing key I have used for all previous runc releases. You
can also verify that this is the key trusted by openSUSE for all of our
releases.

Ref: https://keyserver.ubuntu.com/pks/lookup?search=5F36C6C61B5460124A75F5A69E18AA267DDB8DB4&fingerprint=on&op=index
Ref: https://build.opensuse.org/package/view_file/openSUSE:Factory/runc/runc.keyring?expand=1&rev=54
Signed-off-by: Aleksa Sarai <asarai@suse.de>
keyid C9C370B246B09F6DBCFC744C34401015D1D2D386

This is my personal signing key, which I've used to sign the vast
majority of my commits on GitHub. While I usually sign releases using my
<asarai@suse.de> signing key, it doesn't hurt to include this key too.

Ref: https://keyserver.ubuntu.com/pks/lookup?search=C9C370B246B09F6DBCFC744C34401015D1D2D386&fingerprint=on&op=index
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Copy link
Contributor

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@AkihiroSuda AkihiroSuda merged commit 3a2c0c2 into opencontainers:main Apr 19, 2023
@cyphar cyphar deleted the release-gpgkeys branch April 22, 2023 07:09
@kolyshkin kolyshkin added backport/1.1-done A PR in main branch which has been backported to release-1.1 and removed backport/1.1-todo A PR in main branch which needs to be backported to release-1.1 labels May 22, 2023
@kolyshkin
Copy link
Contributor

1.1 backport: #3838

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport/1.1-done A PR in main branch which has been backported to release-1.1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants