On Sat, 2 Jun 2012 15:28:03 -0400
Gregory Maxwell <gmaxw...@gmail.com> wrote:

> 
> If the issue were just the opaque and unpredictable behavior on
> failure this could be addressed without signing any of the
> distribution proper.
> 
> Create a pre-bootloder.  If secureboot is enabled only permitting this
> boot because it's signed with the msft key,  then display the most
> helpful instructions WRT secureboot we can display and then halt.   If
> secureboot is not enabled, pass control to grub.

Sure, this gets back to the "what do we tell the user". 

"Go into your EFI setup somehow (depends on vendor) and find something
like "secure boot" (but it may be called something else) and find the
thing that disables that (it may be called disable, or you may have to
set 'custom mode' or you may have to remove all keys from it, then
reboot" 

I think we all agree this whole thing sucks, but I think the above is
less than ideal for our users. 

> This should meet the signing requirements and it removes the opacity
> without locking down any of Fedora.  Such a bootloader should meet
> whatever requirements to get signed, since if secureboot is turned on
> it wont boot anything at all.
> 
> I strongly encourage this mode to be created and included with Fedora
> even if goes down the route of locking down the operating system... so
> when people do replace their bootloaders/kernels they're not just
> stuck booting into windows or getting a black screen.

Sure, this is a valid option... and presenting our users with the best
info we can at any of these steps is good. 

kevin

Attachment: signature.asc
Description: PGP signature

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to