-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Conversation
Unfortunately it looks like you cannot give actions write access using (It's also a bit ugly that 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>
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 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 |
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
1.1 backport: #3838 |
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 distributionshould 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