build: Key the Secure Boot signing layers on the certificate - #2498
Open
cgwalters-bot wants to merge 1 commit into
Open
cgwalters-bot wants to merge 1 commit into
cgwalters-bot wants to merge 1 commit into
Conversation
cgwalters
requested changes
Sep 25, 2026
cgwalters
left a comment
cgwalters
left a comment
Collaborator
There was a problem hiding this comment.
This is kind of hacky. I get the problem but what if we copied in the public key into a layer and had a trivial use of that like printing it from our script? I bet that'd work
cgwalters-bot
added a commit
to cgwalters-bot/homegit
that referenced
this pull request
Sep 25, 2026
A URL seen for the first time was only recorded, its comments and reviews marked as seen. That is right for someone else's issue added to the board with its history, but not for a PR the bot just opened: the board cache can lag behind 'bot-pr promote' by a sweep or two, and cgwalters' CHANGES_REQUESTED review on bootc-dev/bootc#2498, 12 minutes after the promote, was swallowed that way. So for an issue or PR the bot opened, first sight reports everything since its creation, with the usual filters (not the bot's own). The created_at comes with the REST read the sweep makes anyway, where the board item's own creation time would cost GraphQL. Seeding the watch state at promote time instead would race with a sweep's read-modify-write of the same state, and only cover promote. The very first sweep, with an empty state, still reports nothing. Generated-by: AI
cgwalters-bot
added a commit
to cgwalters-bot/homegit
that referenced
this pull request
Sep 25, 2026
…sweep bot-watch only reports edges: whatever it sees once is marked seen, so news it misses or reports into a lost output is gone for good, as his review on bootc-dev/bootc#2498 was. For the bot's own open upstream PRs that means lost work, so every sweep now also lists, in its own "Outstanding reviews by cgwalters" section, his latest review requesting changes or commenting, or comment, while it is newer than both the head commit and the bot's last comment or review there. A push or a reply clears it, as does his approval after it. It reuses the reviews the sweep already reads; the head commit and the comments since it are ETag'd REST reads that mostly answer 304. Fork PRs stay 'bot-pr inbox' business. The coordinator treats the section as P0. Generated-by: AI
cgwalters-bot
force-pushed
the
bot/secureboot-cache-key
branch
from
September 25, 2026 15:45
17fd598 to
bb81555
Compare
Contributor
Author
|
Done, that works: the build arg is gone (force-pushed bb81555, same single commit).
Generated-by: https://github.com/cgwalters/#llms |
cgwalters
approved these changes
Sep 25, 2026
cgwalters
left a comment
cgwalters
left a comment
Collaborator
There was a problem hiding this comment.
Feels like the real fix is --mount=type=secret,invalidate or something for podman but yeah looks sane
Collaborator
|
@cgwalters-bot you can add my signoff |
cgwalters-bot
force-pushed
the
bot/secureboot-cache-key
branch
from
September 25, 2026 19:35
bb81555 to
f27d0cb
Compare
Contributor
Author
|
Added your sign-off. Generated-by: https://github.com/cgwalters/#llms |
Build secrets aren't part of the layer cache key, so the steps that sign systemd-boot and the UKIs can be served from cache after the test keys change: after `target/` is wiped and the keys regenerated, or from another checkout sharing the same container storage. The result is an image signed with a key the VM firmware doesn't trust, which fails to boot with "Access Denied" in a way that looks like a real Secure Boot bug. Copy the public certificate into each signing stage from a build context, and print its checksum when signing. Copied content is part of the cache key, so a different certificate rebuilds those steps. Only the certificate is copied; the private key stays a secret. Generated-by: AI Signed-off-by: Colin Walters <walters@verbum.org>
Contributor
Author
|
Rebased onto main; 1 commit, no content change. Generated-by: https://github.com/cgwalters/#llms |
cgwalters-bot
force-pushed
the
bot/secureboot-cache-key
branch
from
September 26, 2026 03:22
f27d0cb to
e2c44d9
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Build secrets aren't part of podman's layer cache key. So the steps that sign systemd-boot and the UKIs (
sdboot-signed,sealed-uki, andsealed-upgrade-ukiintmt/tests/Dockerfile.upgrade) can be served from cache after the test keys change. That happens aftertarget/is wiped, or when two checkouts share container storage. The image then fails Secure Boot with "Access Denied", which looks like a real bug. I hit this while testing several branches on one machine. CI builds one checkout per runner, so it isn't affected.The fix copies the public certificate (
db.crt, from asecurebootbuild context) into each signing stage and prints its checksum when signing. Copied content is part of the cache key, so a different certificate reruns those steps. The private key is still only a build secret. A new signing stage needs the sameCOPY.Tested on a 16-core RHEL 10 devspace, Fedora 44 base, sealed UKI with systemd-boot:
just buildplusjust _build-upgrade-imagetwice with key A, then with a regenerated key B. Round 2 reused the cache (no signing step ran); round 3 reran all three signing steps.sbverifyshows systemd-boot and both UKIs signed with A in rounds 1-2 and with B (not A) in round 3.just validatepasses.Maintainers: this repository requires DCO, and these commits have no
Signed-off-by. To add yours, rungit rebase --signoff <upstream>/mainon this branch and force-push it.Generated-by: https://github.com/cgwalters/#llms