On Fri, Aug 10, 2012 at 03:45:38PM +0200, Olaf Kirch wrote:
SuseStudio doesn't need keys; it doesn't build its own kernels or grub packages - it just pulls them from "somewhere" and puts them into the image.
And just like we don't sign packages in any random build service project with the openSUSE key, we wouldn't be signing kernels from random OBS projects - only the openSUSE kernel would receive this signature.
So in order to build a "malware" kernel and get it signed, you would have to submit that change to the openSUSE project and conceal it sufficiently to pass the review at package check-in.
But what if OBS and/or SuseStudio is used to create a kernel that gets designated as malware. I would like to see the openSUSE solution provide a way to black ball that kernel.
That's a good point. The only alternative would be to revoke the key in that case; and that's not attractive either.
Revocation of keys is something we'll need to discuss. It's not a large problem with keys in the MOK database, but it is a problem for the default SUSE key embedded in the shim. On the other hand, this is a well solved problem, using authenticated UEFI variables, so we may just well use that. The only drawback is that it makes the solution more complex. -- Vojtech Pavlik Director SuSE Labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org