From ecf5bc90cc589bfdb90ca1d89a4bedb1e60a48c1 Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Thu, 12 Mar 2026 21:56:57 -0400 Subject: [PATCH 1/9] docs: GA contributing update with additional ci and repository secret preparation. --- content/CONTRIBUTING.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index 801b804b..9522f54d 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -90,14 +90,24 @@ We strive towards a model where proposed changes are more thoroughly reviewed an ## Building your images with GitHub Actions (recommended) -Start from your own fork with a branch for the pull request/feature you want to develop. Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. From there, it's recommended you go to .github/workflows/build.yml and comment out all of the image variants except the ones you use/intend to test. This drastically speeds up your workflow runtime. Then just go to actions > build-secureblue and select run workflow, making sure you select the branch you just set up. +Start from your own fork with a branch for the pull request/feature you want to develop. Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Also create two copies of your your public singing key in `/etc/pki/containers/` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. -Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. This is a string that starts with 'rpm-ostree rebase ostree-unverified-registry:ghcr.io/', followed by the repo and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}`. Your command should look like this: +You must also add a kernel signing key to your repository secrets as well. You can generate your own or use the X.509 key pair provided in the repository. First Copy `.github/workflows/private_key.priv.test` to a GitHub repository secret called `KERNEL_PRIVKEY` alongside your signing key you created to verify your public image. Then copy the public key `.github/workflows/pub_key.der.test` to `files/system/etc/pki/akmods/certs`. + +From there, it's recommended you go to `.github/workflows/build-all.yml` and comment out all of the image variants except the ones you use/intend to test. Additionally, make sure to change the `github.triggering_actor` to the GitHub username that will trigger the workflow run to build the images you haven't commented out. Then just go to **Actions** > **build** and select run workflow, making sure you select the branch you just set up. + +Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repo and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}`. Your command should look like this: ``` rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:br-YOURBRANCHNAME-42 ``` +However, if you set this branch as your default branch the tag will simply be called `latest`, like so: + +``` +rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:latest +``` + ## [Building Locally](#building-locally) {: #building-locally} From 0716148d7b083809b9e061b2d66e0e44a044bdec Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Thu, 12 Mar 2026 23:05:43 -0400 Subject: [PATCH 2/9] docs: GA grammar, typos, slight rewording of sections. --- content/CONTRIBUTING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index 2a5aba3f..24c33456 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -94,17 +94,17 @@ We strive towards a model where proposed changes are more thoroughly reviewed an Start from your own fork with a branch for the pull request/feature you want to develop. Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Also create two copies of your your public singing key in `/etc/pki/containers/` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. -You must also add a kernel signing key to your repository secrets as well. You can generate your own or use the X.509 key pair provided in the repository. First Copy `.github/workflows/private_key.priv.test` to a GitHub repository secret called `KERNEL_PRIVKEY` alongside your signing key you created to verify your public image. Then copy the public key `.github/workflows/pub_key.der.test` to `files/system/etc/pki/akmods/certs`. +You must also add a kernel signing key to your repository secrets as well. You can generate your own X.509 key pair or use the one provided in the repository. If using the key pair provided, first copy the private key `.github/workflows/private_key.priv.test` to a GitHub repository secret called `KERNEL_PRIVKEY` alongside your signing key you created to verify your public image. Then copy the public key `.github/workflows/pub_key.der.test` to `files/system/etc/pki/akmods/certs`. From there, it's recommended you go to `.github/workflows/build-all.yml` and comment out all of the image variants except the ones you use/intend to test. Additionally, make sure to change the `github.triggering_actor` to the GitHub username that will trigger the workflow run to build the images you haven't commented out. Then just go to **Actions** > **build** and select run workflow, making sure you select the branch you just set up. -Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repo and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}`. Your command should look like this: +Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repo and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}` or just `latest` if it the image is built on your repository's default branch. If your image is not built on the default branch, your command should look like this: ``` rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:br-YOURBRANCHNAME-42 ``` -However, if you set this branch as your default branch the tag will simply be called `latest`, like so: +Likewise, on the default branch your command will look like this: ``` rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:latest From d85823436d2a277becd6d5eebb037f6ae4c180f5 Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Fri, 13 Mar 2026 01:04:28 -0400 Subject: [PATCH 3/9] docs: GA contributing separated into sections+recommended git workflow for PRs --- content/CONTRIBUTING.md | 83 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 80 insertions(+), 3 deletions(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index 24c33456..b4906198 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -26,6 +26,11 @@ And if you like the project, but just don't have time to contribute, that's fine - [Pull Requests](#pull-requests) - [How to test incoming changes](#how-to-test-incoming-changes) - [Building with GitHub Actions (recommended)](#building-ga) + - [Setting up your test build branch](#test-branch-ga) + - [Preparing Image and Kernel signing key](#signing-keys-ga) + - [Preparing GitHub Actions CI Workflow](#workflow-ga) + - [Recommended Git Workflow for Pull Requests](#workflow-git) + - [Building and Rebasing to your Image Repository](#rebase-ga) - [Building Locally](#building-locally) - [Styleguides](#styleguides) - [Commit Messages](#commit-messages) @@ -92,13 +97,85 @@ We strive towards a model where proposed changes are more thoroughly reviewed an ## [Building with GitHub Actions (recommended)](#building-ga) {: #building-ga} -Start from your own fork with a branch for the pull request/feature you want to develop. Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Also create two copies of your your public singing key in `/etc/pki/containers/` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. +Building with GitHub Actions allows you to create your own bootable images to rebase your Fedora Atomic installation to in order to test pull requests/features you are developing. + +### [Setting up your test build branch](#test-branch-ga) +{: #test-branch-ga} + +Start from your own fork with a branch for building your images. It is recommended to keep the branch you want to build your images on separate from branches you want to create pull requests for to keep the changes to your workflow separate from your feature changes and avoid merge conflicts. You can create a test branch called `test-build` by doing the following: + +``` +# fetch from secureblue remote if you haven't already done so. +git remote add upstream https://github.com/secureblue/secureblue +git fetch upstream +# create your test-build branch based on upstream/live +git switch -c test-build upstream/live +``` + +### [Preparing Image and Kernel signing key](#signing-keys-ga) +{: #signing-keys-ga} + +Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Also create two copies of your your public singing key in `/etc/pki/containers/` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. You must also add a kernel signing key to your repository secrets as well. You can generate your own X.509 key pair or use the one provided in the repository. If using the key pair provided, first copy the private key `.github/workflows/private_key.priv.test` to a GitHub repository secret called `KERNEL_PRIVKEY` alongside your signing key you created to verify your public image. Then copy the public key `.github/workflows/pub_key.der.test` to `files/system/etc/pki/akmods/certs`. -From there, it's recommended you go to `.github/workflows/build-all.yml` and comment out all of the image variants except the ones you use/intend to test. Additionally, make sure to change the `github.triggering_actor` to the GitHub username that will trigger the workflow run to build the images you haven't commented out. Then just go to **Actions** > **build** and select run workflow, making sure you select the branch you just set up. +### [Preparing GitHub Actions CI Workflow](#workflow-ga) +{: #workflow-ga} + +To prepare the CI workflow in GitHub Actions, it's recommended you go to `.github/workflows/build-all.yml` and comment out all of the image variants except the ones you use/intend to test. For the images you haven't comented out, you must make sure to change the `github.triggering_actor` to the GitHub username that will trigger the workflow. + +### [Recommended Git Workflow for Pull Requests](#workflow-git) +{: #workflow-git} + +This is a recommended git workflow you can adopt, assuming you've already [created a test build branch](#test-branch-ga) called `test-build` tracking the upstream secureblue repository. + +Once all of your [signing keys](#signing-keys-ga) and [GitHub workflow](#workflow-ga) changes ready on `test-build`, commit your changes and create a tag called `test-build-setup` so we can reset to it later: + +``` +git add . +git commit -m "DO NOT MERGE: test-build setup" +git tag -f test-build-setup +git push origin test-build +``` + +You then may want to create a branch for your pull request/feature based on `upstream/live`, for example: + +``` +git switch -c new-feature upstream/live +# ... do the changes ... +git add . +git commit -m "feat: ducks can now fly" +git push origin new-feature +``` + +Switch back to `test-build` and cherry pick or merge your changes from `new-feature`. + +``` +git switch test-build +git cherry-pick # or simply 'git merge new-feature' for the full branch. +git push origin test-build +``` + +You may then go on to [build and rebase to your image](#rebase-ga) to test your pull request. + +After you're done testing your feature, you can reset your test branch by doing the following: + +``` +git switch test-build # make sure we're on test-build +git reset --hard upstream/live +git cherry-pick test-build-setup # this is where the tag comes in hand +# can cherry-pick more commits or just add more commits for testing purpose +git push --force-with-lease origin test-build +``` + +### [Building and Rebasing to your Image Repository](#rebase-ga) +{: #rebase-ga} + +Once everything is ready, go to **Actions** > **build** and select run workflow, making sure you select the branch you just set up. + +Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. If you're working from a secureblue image which rejects container images by default, make sure to [add your image repository to the container policy](/faq#container-policy). Your image repository is called `ghcr.io/YOURUSERNAME`. -Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repo and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}` or just `latest` if it the image is built on your repository's default branch. If your image is not built on the default branch, your command should look like this: +This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repo and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}` or just `latest` if it the image is built on your repository's default branch. If your image is not built on the default branch, your command should look like this: ``` rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:br-YOURBRANCHNAME-42 From 5f9b35cb905de404e20e5fea00976437af364319 Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Fri, 13 Mar 2026 01:08:57 -0400 Subject: [PATCH 4/9] fix: GA contributing whitespace line 130. --- content/CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index b4906198..8e304d86 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -127,7 +127,7 @@ To prepare the CI workflow in GitHub Actions, it's recommended you go to `.githu ### [Recommended Git Workflow for Pull Requests](#workflow-git) {: #workflow-git} -This is a recommended git workflow you can adopt, assuming you've already [created a test build branch](#test-branch-ga) called `test-build` tracking the upstream secureblue repository. +This is a recommended git workflow you can adopt, assuming you've already [created a test build branch](#test-branch-ga) called `test-build` tracking the upstream secureblue repository. Once all of your [signing keys](#signing-keys-ga) and [GitHub workflow](#workflow-ga) changes ready on `test-build`, commit your changes and create a tag called `test-build-setup` so we can reset to it later: From 7d7e8a3bef0dfb6bf475f3442136e29a5e1058c4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Renato?= <259754904+underscorejoser@users.noreply.github.com> Date: Fri, 13 Mar 2026 17:04:12 +0000 Subject: [PATCH 5/9] improve code blocks and misc Co-authored-by: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> --- content/CONTRIBUTING.md | 50 ++++++++++++++++++++++++++++------------- 1 file changed, 34 insertions(+), 16 deletions(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index 8e304d86..114c1f1e 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -102,13 +102,16 @@ Building with GitHub Actions allows you to create your own bootable images to re ### [Setting up your test build branch](#test-branch-ga) {: #test-branch-ga} -Start from your own fork with a branch for building your images. It is recommended to keep the branch you want to build your images on separate from branches you want to create pull requests for to keep the changes to your workflow separate from your feature changes and avoid merge conflicts. You can create a test branch called `test-build` by doing the following: +Start from your own fork with a branch for building your images. It is recommended to keep the branch you want to build your images on separate from branches you want to create pull requests for to keep the changes to your workflow separate from your feature changes and avoid merge conflicts. You can create a build branch called `test-build` by doing the following: -``` -# fetch from secureblue remote if you haven't already done so. +```sh +# Add upstream remote if wasn't already added git remote add upstream https://github.com/secureblue/secureblue -git fetch upstream -# create your test-build branch based on upstream/live + +# Fetch latest changes from upstream/live +git fetch upstream live + +# Create your test-build branch based on upstream/live git switch -c test-build upstream/live ``` @@ -129,9 +132,9 @@ To prepare the CI workflow in GitHub Actions, it's recommended you go to `.githu This is a recommended git workflow you can adopt, assuming you've already [created a test build branch](#test-branch-ga) called `test-build` tracking the upstream secureblue repository. -Once all of your [signing keys](#signing-keys-ga) and [GitHub workflow](#workflow-ga) changes ready on `test-build`, commit your changes and create a tag called `test-build-setup` so we can reset to it later: +Once all of your [signing keys](#signing-keys-ga) and [GitHub workflow](#workflow-ga) changes ready on `test-build`, commit your changes and create a tag called `test-build-setup` so we can use it later: -``` +```sh git add . git commit -m "DO NOT MERGE: test-build setup" git tag -f test-build-setup @@ -140,9 +143,13 @@ git push origin test-build You then may want to create a branch for your pull request/feature based on `upstream/live`, for example: -``` +```sh +# Fetch latest changes from upstream/live +git fetch upstream live git switch -c new-feature upstream/live -# ... do the changes ... + +# ... Do the changes ... + git add . git commit -m "feat: ducks can now fly" git push origin new-feature @@ -150,21 +157,32 @@ git push origin new-feature Switch back to `test-build` and cherry pick or merge your changes from `new-feature`. -``` +```sh git switch test-build -git cherry-pick # or simply 'git merge new-feature' for the full branch. +git cherry-pick # Or simply 'git merge new-feature' for the full branch. git push origin test-build ``` You may then go on to [build and rebase to your image](#rebase-ga) to test your pull request. -After you're done testing your feature, you can reset your test branch by doing the following: +You can sync your build branch with upstream by doing the following: -``` -git switch test-build # make sure we're on test-build +```sh +# Make sure we're on test-build +git switch test-build + +# Fetch latest changes from upstream/live +git fetch upstream live + +# Reset the branch to upstream/live git reset --hard upstream/live -git cherry-pick test-build-setup # this is where the tag comes in hand -# can cherry-pick more commits or just add more commits for testing purpose + +# Cherry pick the tag defined before +git cherry-pick test-build-setup + +# ... Cherry pick or commit changes ... + +# Push rewriting the history git push --force-with-lease origin test-build ``` From 1f2d602e30d2d0a4595174c456528d938b66a3a7 Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Sat, 14 Mar 2026 12:15:36 -0400 Subject: [PATCH 6/9] docs: security implications of kernel signing keys, other improvements to GA. --- content/CONTRIBUTING.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index 114c1f1e..eafad859 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -118,9 +118,9 @@ git switch -c test-build upstream/live ### [Preparing Image and Kernel signing key](#signing-keys-ga) {: #signing-keys-ga} -Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Also create two copies of your your public singing key in `/etc/pki/containers/` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. +Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Then create two copies of your your public singing key in `files/system/etc/pki/containers` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. -You must also add a kernel signing key to your repository secrets as well. You can generate your own X.509 key pair or use the one provided in the repository. If using the key pair provided, first copy the private key `.github/workflows/private_key.priv.test` to a GitHub repository secret called `KERNEL_PRIVKEY` alongside your signing key you created to verify your public image. Then copy the public key `.github/workflows/pub_key.der.test` to `files/system/etc/pki/akmods/certs`. +You must also add a kernel signing key to your repository secrets for verifying kernel modules. [The kernel signing makes use of an X.509 certificate](https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html), in which you can generate your own or use the test key pair provided in the repository. Note that the key pair in the repository is for test purposes only, as using it in production would allow the loading of malicious kernel modules that seem legitimate. If using the test key pair provided, first copy the private key `.github/workflows/private_key.priv.test` to a GitHub repository secret called `KERNEL_PRIVKEY` alongside your signing key you created to verify your public image. Then copy the public key `.github/workflows/pub_key.der.test` to `files/system/etc/pki/akmods/certs/`. ### [Preparing GitHub Actions CI Workflow](#workflow-ga) {: #workflow-ga} @@ -151,7 +151,7 @@ git switch -c new-feature upstream/live # ... Do the changes ... git add . -git commit -m "feat: ducks can now fly" +git commit -S -m "feat: ducks can now fly" git push origin new-feature ``` @@ -193,10 +193,10 @@ Once everything is ready, go to **Actions** > **build** and select run workflow, Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. If you're working from a secureblue image which rejects container images by default, make sure to [add your image repository to the container policy](/faq#container-policy). Your image repository is called `ghcr.io/YOURUSERNAME`. -This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repo and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}` or just `latest` if it the image is built on your repository's default branch. If your image is not built on the default branch, your command should look like this: +This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repository and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}` or just `latest` if it the image is built on your repository's default branch. If your image is not built on the default branch, your command should look like this: ``` -rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:br-YOURBRANCHNAME-42 +rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:br-YOURBRANCHNAME-43 ``` Likewise, on the default branch your command will look like this: From 050199d3fdc89d2490ede43cf75af1741673744b Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Sat, 14 Mar 2026 14:01:42 -0400 Subject: [PATCH 7/9] docs: signing-keys-ga correct cosign key file path --- content/CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index eafad859..d4d962b9 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -118,7 +118,7 @@ git switch -c test-build upstream/live ### [Preparing Image and Kernel signing key](#signing-keys-ga) {: #signing-keys-ga} -Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Then create two copies of your your public singing key in `files/system/etc/pki/containers` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. +Follow the instructions [here](https://blue-build.org/how-to/cosign/) to add your own keys to verify your own custom image. Then create two copies of your your public singing key in `files/system/etc/pki/containers/` called `GITHUB_REPOSITORY_OWNER-2025.pub` and `GITHUB_REPOSITORY_OWNER.pub`. You must also add a kernel signing key to your repository secrets for verifying kernel modules. [The kernel signing makes use of an X.509 certificate](https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html), in which you can generate your own or use the test key pair provided in the repository. Note that the key pair in the repository is for test purposes only, as using it in production would allow the loading of malicious kernel modules that seem legitimate. If using the test key pair provided, first copy the private key `.github/workflows/private_key.priv.test` to a GitHub repository secret called `KERNEL_PRIVKEY` alongside your signing key you created to verify your public image. Then copy the public key `.github/workflows/pub_key.der.test` to `files/system/etc/pki/akmods/certs/`. From c80453a06dcfd1c0a2101bc7e3ce7b248d2932f0 Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Sat, 14 Mar 2026 14:03:01 -0400 Subject: [PATCH 8/9] docs: reword #test-branch-ga 'on' and 'for' to to just 'from' --- content/CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index d4d962b9..706a1f2e 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -102,7 +102,7 @@ Building with GitHub Actions allows you to create your own bootable images to re ### [Setting up your test build branch](#test-branch-ga) {: #test-branch-ga} -Start from your own fork with a branch for building your images. It is recommended to keep the branch you want to build your images on separate from branches you want to create pull requests for to keep the changes to your workflow separate from your feature changes and avoid merge conflicts. You can create a build branch called `test-build` by doing the following: +Start from your own fork with a branch for building your images. It is recommended to keep the branch you want to build your images from separate from branches you want to create pull requests from to keep the changes to your workflow separate from your feature changes and avoid merge conflicts. You can create a build branch called `test-build` by doing the following: ```sh # Add upstream remote if wasn't already added From 433b755e4bb63a64a54540b5a94e414680fe59e9 Mon Sep 17 00:00:00 2001 From: Jordan Herzstein <63795875+jherzstein@users.noreply.github.com> Date: Sat, 14 Mar 2026 16:23:48 -0400 Subject: [PATCH 9/9] docs: #workflow-ga typo, make #rebase-ga more clear, image repository->registry. --- content/CONTRIBUTING.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/CONTRIBUTING.md b/content/CONTRIBUTING.md index 706a1f2e..443021f8 100644 --- a/content/CONTRIBUTING.md +++ b/content/CONTRIBUTING.md @@ -125,7 +125,7 @@ You must also add a kernel signing key to your repository secrets for verifying ### [Preparing GitHub Actions CI Workflow](#workflow-ga) {: #workflow-ga} -To prepare the CI workflow in GitHub Actions, it's recommended you go to `.github/workflows/build-all.yml` and comment out all of the image variants except the ones you use/intend to test. For the images you haven't comented out, you must make sure to change the `github.triggering_actor` to the GitHub username that will trigger the workflow. +To prepare the CI workflow in GitHub Actions, it's recommended you go to `.github/workflows/build-all.yml` and comment out all of the image variants except the ones you use/intend to test. For the images you haven't commented out, you must make sure to change the `github.triggering_actor` to the GitHub username that will trigger the workflow. ### [Recommended Git Workflow for Pull Requests](#workflow-git) {: #workflow-git} @@ -191,12 +191,12 @@ git push --force-with-lease origin test-build Once everything is ready, go to **Actions** > **build** and select run workflow, making sure you select the branch you just set up. -Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. If you're working from a secureblue image which rejects container images by default, make sure to [add your image repository to the container policy](/faq#container-policy). Your image repository is called `ghcr.io/YOURUSERNAME`. +Once it's done building, go to your VM running Fedora Atomic and rebase to your newly built image. If you're working from a secureblue image which rejects container images by default, make sure to [add your image registry to the container policy](/faq#container-policy). Your image registry is called `ghcr.io/YOURUSERNAME`. -This is a string that starts with `rpm-ostree rebase ostree-unverified-registry:ghcr.io/`, followed by the repository and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the repo and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}` or just `latest` if it the image is built on your repository's default branch. If your image is not built on the default branch, your command should look like this: +To rebase to your image on your remote registry without a signature, your command will start with `rpm-ostree rebase ostree-unverified-registry:`, followed by the registry and package name. This can be found by checking the "packages" section in the sidebar of your fork. Take the docker pull command and copy the registry and package reference. Then, append the tag, which is in the format `br-{branchName}-{fedoraVersion}` (e.g. `br-test-build-43`) or just `latest` if it the image is built on your repository's default branch. If your image is not built on the default branch, your command should look like this: ``` -rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:br-YOURBRANCHNAME-43 +rpm-ostree rebase ostree-unverified-registry:ghcr.io/YOURUSERNAME/YOURIMAGENAME:br-YOURBRANCHNAME-FEDORAVERSION ``` Likewise, on the default branch your command will look like this: