Do we have the same security issue for edk2 Ubuntu package or not? If yes, then what edk2 package maintainers think about the ways to handle it? I believe that we have to sync about approaches to the problem.
---
btw, I have played with https://pypi.org/project/virt-firmware/ a little bit and I was able to generate NVRAM file with Secure Boot enabled and some extra certificates enrolled. It looks like that:
virt-fw-vars -i OVMF_VARS.4MB.fd -o OVMF_VARS.4MB.ms.fd --distro-keys windows --set-pk 64e53e5c-5b54-4095-bd2e-4a8fceb7b4c3 ../ubuntu-sb.pem --add-kek 64e53e5c-5b54-4095-bd2e-4a8fceb7b4c3 ../ubuntu-sb.pem --sb
I think we can replace existing "edk2-vars-generator"-based solution with this. The only problem is that final UUIDs are not the same as we have after edk2-vars-generator. We can solve that by hard-coding microsoft certificates with the same UUIDs as we have them now instead of using "--distro-keys windows" option.
Hm, I'm looking into the packaging code for edk2 package in Ubuntu and as far as I understand it has the same problem as we discuss here, right?
https:/ /git.launchpad. net/ubuntu/ +source/ edk2/tree/ debian/ rules?h= applied/ ubuntu/ noble-devel
I can't see BUILD_SHELL=FALSE anywhere.
Do we have the same security issue for edk2 Ubuntu package or not? If yes, then what edk2 package maintainers think about the ways to handle it? I believe that we have to sync about approaches to the problem.
---
btw, I have played with https:/ /pypi.org/ project/ virt-firmware/ a little bit and I was able to generate NVRAM file with Secure Boot enabled and some extra certificates enrolled. It looks like that: 5b54-4095- bd2e-4a8fceb7b4 c3 ../ubuntu-sb.pem --add-kek 64e53e5c- 5b54-4095- bd2e-4a8fceb7b4 c3 ../ubuntu-sb.pem --sb
virt-fw-vars -i OVMF_VARS.4MB.fd -o OVMF_VARS.4MB.ms.fd --distro-keys windows --set-pk 64e53e5c-
I think we can replace existing "edk2-vars- generator" -based solution with this. The only problem is that final UUIDs are not the same as we have after edk2-vars- generator. We can solve that by hard-coding microsoft certificates with the same UUIDs as we have them now instead of using "--distro-keys windows" option.