I have read about secure boot in fedora.
"Most hardware you'll be able to buy towards the end of the year will be Windows 8 certified. That means that it'll be carrying a set of secure boot keys, and if it comes with Windows 8 pre-installed then secure boot will be enabled by default. This set of keys isn't absolutely fixed and will probably vary between manufacturers, but anything with a Windows logo will carry the Microsoft key."
So i guess motherboards won't have it enabled by default. But if i buy for example a windows infected machine (i.e a laptop) i will have the damn key.
"The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key."
So they will pay a microsoft tax. I would not use anything which provides revenue to microsoft. Even if it's a rather symbolic sum.
My fear is there will be signed hardware where disabling secure boot won't be an option. I wouldn't like linux-wide M$ certification. Does the mint team have a position on that ?
Questions about the project and the distribution - obviously no support questions here please
2 posts • Page 1 of 1
My understanding is that, at least on the x86-64 platform, Microsoft's Windows 8 certification requirements include that the firmware provide a way to disable the Secure Boot feature. Thus, you should be able to get around that, at least for Windows 8 and at least on the x86-64 platform. (My understanding is that this is not the case for ARM, where the requirements specify that it should not be possible to disable Secure Boot.) The big problem is that the user interface for all of this is completely undefined. That is, Manufacturer A might enable you to disable Secure Boot using one method, whereas Manufacturer B might use a different method, and Manufacturer C might use a third. This makes it next to impossible to document how to do the task in a "generic" way. It'll be a mess and it'll turn off a lot of newbies.