it can be added to your own projects built from main though, see j0rge's link
it can be added to your own projects built from main though, see j0rge's link
JPR build failed btw
Kyeah, failing to pull locally
Kmay need EyeCantCU's eyes
Ryep, it just means every downstream project now has to manage kernel signing
Rand it means that there's a manual step regardless for those projects since we don't have access to the privkey to sign with so a new key would need to be manually imported by users
Rso downstream projects would be more or less left out to dry
Rwhich like, is well within your right to do
Rbut it would be nice not to
Kunfortunately this is fedora's fuck up, I don't have a quick fix
Keven for bluefin
Ri know. also wait shouldn't you be signing the kernel with the existing key?
Rif you use the akmods key won't bluefin users need to reimport?
Kbazzite does (and so far is immune to this issue)
Kbluefin and main on stock fedora kernel leave the keys alone
Kand only sign the akmods
Kso most people have this key enrolled already for akmods
Ryikes, so bluefin users will still see this issue unless they manually import?
Kthose that don't will continue to see the issue
Roh I see
Rwait, this is the same as the secureboot key https://github.com/ublue-os/config/blob/main/build/ublue-os-just/00-default.just
Kyes, the kernel is signed with fedora's key (valid anywhere you'd find secure boot)
Kand the akmods are signed with the akmod key (required for akmods to load under secure boot)
Kchange is to also sign the kernel with the akmod key
Rright, so this could still be added to main to help downstream projects, despite not having a reason to be in main until this point
Kpotentially, yes
Ri get that you don't have to
Kwould require pulling the akmod key into main and porting this over
Kright now that key is not present
Rif I had access to your privkey, then i could put that into my repos 
Rbut i cant
Rand you shouldnt give it to me
Rdownstream image users that use nvidia/asus/hwe already have this imported thankfully, so adding it to main would make it uniform
Kyeah, and hwe
Bactually, the secure boot signing key (AND our cosign key) is an org global secrets, so we could use it in main if the choice was made to sign the whole kernel there, but i'm not yet convinced we should do so, even if it is the right choice for bluefin
Kthe signing action has a self-check
Kthat uses the key located in /etc/pki bla bla bla
Kthat won't be there (unless it's added)
Bright, the global secret would need to be injected at the correct location as part of a build step
KYep
K@j0rge that error might be transitory now that I think about it
Kwe aren't
:latest in a PRJshould I rerun the checks?
Krerunning them would do nothing
Kwould have to merge
Kor make some not-to-be-merged version that is purely for testing
Jwell, it's already broken so what do we have to lose?
Kyour call
Bspeaking of calls... have a second?
Ksure, I was about to get lunch and get back to real work, I'll call you in a moment
