On Wed, 2012-09-19 at 15:50 +0200, Nicolas Chauvet wrote: Well, for me personally, it would be kmod-staging, but I suspect we'll have more users interested in having the binary NVidia or Catalyst drivers signed. As I understand it, new computers with Windows 8 preinstalled will have SecureBoot enabled by default, and Fedora 18 will be able to boot on these computers without any change in BIOS settings. The problem is that, if I've got it right, the kernel will refuse to load unsigned modules if SecureBoot is on. So, as I see it, we will need to either: A. Tell users to turn off SecureBoot if they want to use any kmods B. Create an RPM Fusion key, sign kmods with it, and work out some method for getting the public key on the system, preferably without requiring user intervention, though that last bit might be a pipe dream. If we're going to do (A), I think we need to document it very clearly. Something like "Kmods will not work unless SecureBoot is disabled. To disable SecureBoot, please consult your BIOS documentation." If we're going to do (B), I think now would be a good time to start investigating how it will work. According to the link in my original email, the Fedora kernel developers have been stabilized the kernel module signing interface specifically so "third party repositories" can start working out how to sign out-of-tree modules. I'd be happy to start looking into (B) if nobody else is working on it and if this is the road RPM Fusion wants to go down. I'm not a kernel developer, so I'm probably not the best person for the task, but I'd rather see if I can come up with something rather than having us do (A) because of inertia. If I've missed something in all this, please feel free to correct me, and if there are other alternatives that I've missed, please share them. Jonathan

2012/9/20 Jonathan Dieter <jdieter(a)gmail.com&gt;: Well... when asking for this question I had in mind that the nvidia case was out of the topic because of the lack of KMS support, but since modesetting seems to be done in kernel land that might be pointless. (unless PCI regions are also accessed from the Xorg userland). http://lwn.net/Articles/515410/ Then I don't know what about ndiswrapper case ? Maybe it worth to have the windows hardware signature to be verified in such case. (specially for future hardware, when F18 will be EOL. But it's more a corner case, ndiswrapper shoudn't be very used that much nowadays) So a quick answear: the secure boot feature for RPM Fusion really is a "must have". But I'd welcome more people to help with this tasks. Specially: - Sorting out the infrastructures needs (sigul, what's on the builder ?) - kmodtool modification (signature can be opt-in/opt-out ?). - wiki for users / developers (using their own key ?) - Packaging of the root CA used to sign the module (Can cacert.org be a root CA for secure boot ?) I've started a wiki here: http://rpmfusion.org/Howto/Secure%20Boot for users and for infra: http://rpmfusion.org/Infrastructure/Secure%20Boot%20Infra If someone wants to help out. Thx Nicolas (kwizart)