En lisant l'article de Matthew Garrett
http://mjg59.dreamwidth.org/12368.html on découvre que le premier bootloader de Fedora 18, une sorte de stub rarement modifié si ma compréhension est bonne, sera désormais non modifiable par l'utilisateur et signé par Microsoft...
Et le second bootloader, qui sera appelé par le premier et qui fera le job, sera lui aussi non modifiable par l'utilisateur et signé mais par Fedora....
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 edit: The $99 goes to Verisign, not Microsoft - further edit: once paid you can sign as many binaries as you want), 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
We've decided to take a multi-layer approach to our signing for a fairly simple reason. Signing through the Microsoft signing service is a manual process, and that's a pain. We don't want to have bootloader updates delayed because someone needs to find a copy of Internet Explorer and a smartcard and build packages by hand. Instead we're writing a very simple bootloader[2]. This will do nothing other than load a real bootloader (grub 2), validate that it's signed with a Fedora signing key and then execute it. Using the Fedora signing key there means that we can build grub updates in our existing build infrastructure and sign them ourselves. The first stage bootloader should change very rarely, and we don't envisage updating it more than once per release cycle. It shouldn't be much of a burden on release management.
What about grub? We've already switched Fedora 18 over to using grub 2 by default on EFI systems, but it still needs some work before it's ready for secure boot. The first thing is that we'll be disabling the module loading. Right now you can load arbitrary code into grub 2 at runtime, and that defeats the point of secure boot. So that'll be disabled. Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled.
Cela pose quand même une question: pourra-t-on encore parler de système d'exploitation libre à propos de Fedora ?
Comment ces deux bootlaoders non modifiables signés par Microsoft et Fedora vont-ils s'inscrire dans la politique open source de Fedora:
http://fedoraproject.org/wiki/Licensing
Quelle implication cela va-t-il avoir dans l'usage des DRM et ne va-t-on à terme se retrouver obliger d'utiliser un système d'exploitation gérant ceux-ci ?
Ne va-t-il pas être judicieux de chosir une machine sur laquelle il sera possible de disabler SecureBoot et d'abandonner Fedora pour une autre distribution qui n'incorpore pas ce mécanisme SecureBoot ?
Je suis convaincu que si RedHat et Fedora veulent absolument s'engager dans cette voie il faut à coté de la version SecureBoot signée une version non-SevureBoot sans aucune signature...