#975 Should Fedora 18 Beta be released without signed Secure boot support?
Closed None Opened 11 years ago by kevin.

We failed to discuss this in the meeting, but we should decide this asap:

Currently we don't have a signed shim available, so our composes will not correctly boot on secure boot enabled machines.

Is this a blocker for Beta?
See: https://bugzilla.redhat.com/show_bug.cgi?id=872272

We need to decide this today to potentially stop the rc1 (or if there is a rc2) from becoming beta.


My take: I do think testing this and having it in beta is important, however, I think waiting for an indeterminate time for it to happen is not something we can really do at this point. So, I would be a sad vote for allowing Beta without the signed support if it otherwise is ready to release.

Post beta/as soon as we have a signed shim we could do special composes asking for testers with that support.

A test day perhaps as well?

From the scheduling POV, not being FESCo member - I'd prefer not blocking Beta release as proposed by Kevin (in case we would be ready to Go before signed shim is available) although we definitely need wider testing of this feature (special post Beta compose, Test Day would be useful in both variants).

It leads to the question - is for Beta bigger concern that it's not going to work on the new HW or testing actually signed shim? Wouldn't be signing by Fedora/test key enough to make sure the feature works as expected (with how to for testers)?

For final, it's probably different story - W8 hardware is becoming more common.

+1 to block, though I'd like very much to know what the ETA on signing is.

Replying to [comment:7 limb]:

+1 to block, though I'd like very much to know what the ETA on signing is.

As far as I'm aware, there's no ETA known. But in case we are going to block on SB - is FESCo going to set a deadline for signed shim for Beta or does it mean a free pass for SB (eg. indefinite time)?

-1 to blocking beta for an uncertain and unbounded amount of time.

IIRC the original plan was to have this all enabled by beta; beta has slipped for two months, so the legal negotiations have presumably slipped by at least two months already, and there's nothing to say they will not slip for another two or more.

Also, the owners of new hardware don't care whether we release now without !SecureBoot or whether we delay the release for it - they can't install Fedora "right now" in either case. Releasing with !SecureBoot only helps those who buy the hardware / decide to install Fedora after we release - and the more we slip, the fewer those people are.

Ultimately the choice seems to be between inconveniencing users who will have bought new hardware after F18 release (given an assumed HW upgrade cycle of ~4 years, and a 6-month time between F19 and F18, that should be about 10-15% of our users), and inconveniencing every contributor by delaying the release.

If we block beta, what is the plan? We just sit there frozen until a signed shim shows up? We fork off a Beta package set, unfreeze for post-Beta development, and stick the signed shim in the now-old Beta package set whenever it shows up, and release that? We just unfreeze and make everyone go through the blocker treadmill yet again whenever the signed shim shows up? Or what?

If I had to say right now, I'd say:

{{{
-1 to blocking beta on final MSFT-signed version
+1 to blocking beta on self-signed version in updates-pending
+1 to blocking final on final MSFT-signed version
}}}
Having the self-signed version allows for testing of SecureBoot, and we can substitute the final version once it's available (and we would hold RC and final for that.)

I'm ditto what notting said.

Peter, Matthew - do you think it would be doable - to release Beta with self signed shim and what would be ETA for this? If we could make it this way asap (but I expect not for tmrw's Go/No-Go), then we can stay frozen, slip and it should be "ok". Otherwise if we are waiting for MS signed shim, then I'd be more for post-Beta development as Adam suggested above (but probably only for a limited time, if it would take more time, then we would have to do the last).

we could do an RC2 with the self-signed shim today and still possibly make go/no-go, since it's a very isolated and self-contained change, all non-EFI validation would be valid from RC1 for RC2.

Well, I see we have self signed shim in updates-testing.

Could FESCo members vote on notting's proposal again? Seems like a good compromise if we consider current state of Beta (and it's currently unclear from the ticket what's the resolution;-). We need a clear decision before the Go/No-Go meeting.

No, I don't think the self-signed version gives any worthwhile test coverage.

Sorry, I should clarify that. The majority of users are either going to be using Microsoft-signed loaders or just turning Secure Boot off entirely. People using our keys are going to be in a very small minority. If we're not going to block for a Microsoft signature then I don't think there's any benefit in holding things up for a self-signed image.

for any other idiots who need the long version (er, that is an insult to no-one, I was implying that I'm an idiot who needed a long version):

the self-signed shim is not a 'compromise position', really. the intent was to have it in beta all along, it just got missed being pushed to stable.

here are the practical upshots of the three possible configurations:

1) we ship RC1 as is: the upshot of this is you cannot install Beta with SB enabled at all.

2) we ship Beta with the self-signed shim already available: the upshot of this is that you can install Beta with SB enabled only by manually registering Fedora's own SB key. mjg59 makes the point that this is harder than just disabling SB and hence we do not expect many people to do this, and even for people who take the trouble, their testing tells us little about our actual desired configuration. So he doesn't think it's a big win or worth blocking on. Note that it would be trivial to spin up a special SB testing image with just this change, for people who really wanted to try it. And, I suppose, a netinstall would also pull it in even if we don't put it on the DVD.

3) we ship Beta with a Microsoft-signed shim: the upshot of this is that we have our desired configuration, which actually ought to work on SB-enabled systems OOTB.

Personally I think mjg59's point is a sensible one and it's really not worth blocking on the self-signed shim.

If you're going to block for SB, self-signed shim or otherwise, you will need to do at least one RC2 compose with this dracut update included:

https://admin.fedoraproject.org/updates/FEDORA-2012-18701/dracut-024-10.git20121121.fc18

Without it, the signatures will be stripped off of the modules in the initramfs and in SB mode this will force them to fail insmod. That means things like your rootfs won't be mounted, etc. Basically, it won't boot.

right, we also need the updated dracut for scenarios 2) and 3).

So of the FESCo members I count the votes for blocking on MS-signed SB thus:

nirik -1[[BR]]
notting -1[[BR]]
mjg59 +1[[BR]]
mmaslano ?[[BR]]
pjones +1[[BR]]
jwb ?[[BR]]
tmraz -1[[BR]]
mitr -1[[BR]]
limb +1[[BR]]

that's -4, +3. You need a vote from at least one of mmaslano and jwb in order to declare a decision.

notting and kevin are nominally +1 on blocking for self-signed shim (and presumably dracut), though they may reconsider in light of mjg59's comment. mjg59 is -1. I see no other votes.

Aside from these questions, we're still running validation, but so far, RC1 is looking releasable, and go/no-go meeting is tomorrow. So it's fairly important that this gets settled. jwb, mmaslano, can you please vote? Given mjg59's comments, does anyone still want to push for slipping a week to get a self-signed shim in? At this point, we would need to slip for that change.

Ok, fair enough - test coverage will be definitely smaller with self-signed shim.

Btw. my understanding was, that SB was covered by freezing again (#960, #971) - as no objections were raised that time and SB was not ready, see my comment ;-)

-1

That's -5. The SB is not a blocker for FESCo

To make it clear - MSFT signed shim is not a Beta blocker for now, self-signed one is still blocker (based on kevin's and notting's vote).

Oh, well - I understand now - there are not enough votes now for self-signed blocker.

We don't have any replies this week so I wouldn't block beta on question which was omitted until now.

I'll note that notting said: "+1 to blocking beta on self-signed version in updates-pending"

we do have a self singed shim (and the dract mentioned by jwb to make it work) in updates-pending now.

It does mean beta will not just boot on sb enabled hardware, nor will users be able to import fedora's key and boot that way. All our testing will need to be post beta (as soon as we can sort out MS singed shim). I think that sucks, but it's life. ;(

Ugh. I just realized that I didn't clearly vote in my previous comment. I was +1 to blocker. Not that it matters now.

I'd also be +1 for notting's proposal if we aren't blocking for a MS signed shim.

kevin: as I noted above, unless I'm missing something, any netinstall of Beta should get the updated shim, so netinstall can be used for testing at least.

jreznik: can you close this out?

Login to comment on this ticket.

Metadata