Comment 18 for bug 1788727

This isn't a security issue.

You may have unsigned kernels on your system, but we're planning to have grub enforce signed kernels if Secure Boot is enabled -- therefore we need to catch the case where no kernel is appropriately signed by a key that is known to the firmware or to shim.

There's clearly some issues with the detection (and some limitations) that we're working on addressing right now.

Systems that only have official kernels properly installed should work normally.

Any installs that require custom kernels, or kernels coming from a PPA would likely not be signed (well, they are, but people are unlikely to have the keys installed in firmware), so we need to block upgrade -- it's a better alternative than having your systems fail to boot after the upgrade because we started to install a grub that insists on signed kernels, or because your running kernel is unsigned / not signed by a key that is recognized.

I'm keeping this task open as there's more work needed here to make this a better experience -- we don't /have to/ fail upgrade in all the cases, but it's currently the only thing we can do (and I'm working on improving that).