#67 Trusting the SIGs by default, from a CentOS Project perspective (Secureboot)
Opened 3 years ago by arrfab. Modified 11 months ago

Some time ago, the Hyperscale SIG created an infra ticket asking to be able to build their packages to be working on SecureBoot enabled machines.
This ticket isn't about technical discussion, but more about the underlying question that seems to go in loop between multiple stakeholders when trying to answer the question, so here we go :

What's the official CentOS Project board position on the SIGs and how far they should be trusted ?
RPM packages built by SIGs are actually signed with their dedicated gpg key, and outside of the distro builders infra. But for secureboot, (because of the chain of trust), a kernel built (and signed at build time) with a different key/cert wouldn't boot on the 8-stream because the shim/grub2 packages wouldn't recognize the new key.

Didn't want to dive into tech details, but if we can get an answer from the board about trusting or not the SIGs in such particular situation would be good, and then moving this forward if possible (or just answer "no" to the SIGs)


Thank you for opening the issue, we will look into it. I'll add it to the next board meeting Agenda and Rich requested feedback to all board members.

From the Hyperscale perspective, I'd like to point out that resolving this is pivotal for Hyperscale to continue development of a lot of its deliverables in the CentOS Project.

To note, we're working on live media for the Hyperscale Workstation and cloud images for the Hyperscale Cloud. For both of these, we need to have a proper trust setup so that our built kernels work with the shim and grub2 provided by the project. If it turns out that the Board and the Project does not want to provide us the capability to do this, then we will have to explore other options that are not affiliated with the Project.

None of us want to do that. We like working in the Project, but it's hard for us to prove our technologies to the larger Enterprise Linux community if we're stiffed by the Project itself in a way that prevents us from being successful in making an offering that people can use.

We're trying to operate in good faith within the Project to make it successful, we hope the Board recognizes that and reciprocates in kind.

To give a much needed update here, we did some work behind the scenes to decouple the CentOS Stream shim from the usual development process since we sign those separately. We have the following high-level tasks to complete before we can begin the process of creating roots of trust for SIG content:

  • Update to a recent version of shim in CentOS Stream 8 and 9
  • Submit those builds to Microsoft for signing
  • Draft governance and include contact information from the SIGs for those what will be generating artifacts

These are currently in progress.

Metadata Update from @spotz:
- Issue assigned to bstinson

11 months ago

Log in to comment on this ticket.

Metadata