B@Carl George @M2
we've had some chats going about this topic today and seems better to get it into a thread where we can collaborate
we've had some chats going about this topic today and seems better to get it into a thread where we can collaborate
BOpenSSL is a popular cryptographical toolkit with more than 20 years of history. For a long time, the only way to extend it was by using an "engine", which defines how a cryptographic algorithm is computed.
BBa couple links for context
MThe removal of the engines is definitely a surprise for me. A lot of tooling is based on them and this is parts of the software stack that is usually pretty much unchanging
BThis all got started because I requested
sbsigntools to be added to EPEL10, and it's blocked due to removal of engines (per the jira link above)MSbsigntools I think hasn't been updated since like 2019
BAlso, here's the code which uses engines https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/tree/src/fileio.c so... one option would be for a ublue contributor to update it ...
MAfter an original design in like 2012.
Bwe could fork and contribute upstream, but get it running short term in our own packages/copr
Bif someone is up to tackling that
MI would strongly recommend not having us update this considering that crypto is not something we should be in the business of.
Byeah, i don't think we should own that, but if it's a blocker to us doing signatures, it's at least worth considering as a patch to contribute, but not to maintain
MI'm more curious on what is centOS's current EFI executable story
Bthe alternative is finding a different path to sign
Cnot quite that old, last tag was in 2023
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/tag/?h=v0.9.5
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/tag/?h=v0.9.5
BI did ask @Carl George about this... here's what I wrote for context...
Do you have the insight to point me to where/how CentOS is signing grub, fwupd, kernels, shim?
apparently it's not being done with sbsigntools
but apparently dracut uses sbsigntools when building UKIs so we are feeling confused by this whole change
Balso, my plane is about to land so i have to drop for now, but i'll be back
MI think this is the path I'm mostly considering. I cannot imagine that rhel is removing signing of EFI executables.
My understanding is the mokutil doesn't have any signing capabilities and is reliant on another program for signing. Mokutil as far as I understand it is for interfacing with mokmanager.
My understanding is the mokutil doesn't have any signing capabilities and is reliant on another program for signing. Mokutil as far as I understand it is for interfacing with mokmanager.
Ci don't have a lot of expertise in this area, but i do know the shim signing stuff has been dorked up for a while now, something about the revocation list
MThat would be managed by the sbat
CGitHub
Confirm the following are included in your repo, checking each box: completed README.md file with the necessary information shim.efi to be signed public portion of your certificate(s) embedded in s...
MOr if it's in the firmware. Its in the dbx exclude portion
Cah ha, found it
Ccentos kernels are built in a special "pesign" channel in koji
https://kojihub.stream.centos.org/koji/taskinfo?taskID=5608817
https://kojihub.stream.centos.org/koji/taskinfo?taskID=5608817
Cthat channel has a select set of builders that have access to a hardware hsm, and they use the pesign utility to sign stuff i think
CGitHub
Linux tools for signed PE-COFF binaries. Contribute to rhboot/pesign development by creating an account on GitHub.
MOk. So this is their sbsign
MDoes it have a verifier as well?
MFor centOS. It looks like you guys are on a pre sbat grub. Firmware have those older grubs in the revocation list.
The sbat was introduced because the firmware has extremely limited space. So sbats are a way of declaring what you are so revocations could occur at different parts of the stack
The sbat was introduced because the firmware has extremely limited space. So sbats are a way of declaring what you are so revocations could occur at different parts of the stack
MBut will dig into pesign
MPesign is available in centos-10 repos already
Cnot sure what the verifier part is, i'm out of my depth on secureboot stuff in general
MIt looks like it can list signatures. Worst case we can use sbverify out of band.
We already are basically doing that with the kernel cache right now and all of our builds has a secureboot check.
We already are basically doing that with the kernel cache right now and all of our builds has a secureboot check.
MIt also appears to have a kmod signing tool as well
BI have a branch where I’m trying to get centos akmods going
Right now I’ve added conditions to skip signing and verification, I want to get things going like that first, but then we could use that framework to test out new signing/verification tools
Right now I’ve added conditions to skip signing and verification, I want to get things going like that first, but then we could use that framework to test out new signing/verification tools
Cgood news, i think i figured out a path forward for sbsigntools https://src.fedoraproject.org/rpms/sbsigntools/pull-request/4
Chopefully y'all don't need hsm support
Chere's the upstream commit that added engine support, which my patch reverts https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/commit/?id=efc424c8eea2c398e4371320b4d7266898675ac8
BGreat git spelunking!
Cbuild and submitted, should be in epel-testing tomorrow https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-768b1bfee3
management of Fedora Project updates
Bthank you so much for diving in! more than more of these requests, this one feels above and beyond to get it going.
