@chrismurphy I don't understand why is this a fesco ticket. May I suggest to open a discussion on the devel mailing list instead? I would also suggest to open a bugzilla for shim, but that might not be the best communication channel for the maintainers.

Note that shim doesn't currently build, since late 2018: https://bugzilla.redhat.com/show_bug.cgi?id=1784548 and it has an exception so we don't retire it for that: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/#_packages_exempted_from_this_policy

This is a FESCo ticket because I asked him to file it as one. This is a dangerous situation where we can wind up with a Fedora release that is actually not bootable on computers.

There has already been at least a single indication that this has happened with @chadmccullough's machine: https://twitter.com/chadmccullough/status/1311356891596029952

There are open questions of how we should prioritize this with the Fedora 33 release schedule, and most people seem to agree that is in our wheelhouse, so this is where it got filed.

I would gladly vote for making this a fesco blocker. Is there a tracking bugzilla?

There is a bug report about this failure: https://bugzilla.redhat.com/show_bug.cgi?id=1883609

We can probably make that the tracking bug to block the final release on.

Proposal: https://bugzilla.redhat.com/show_bug.cgi?id=1883609 is a fesco final blocker for fedora 33.

Also proposing as fast track and voting +1.

+1

+1

+1 to making this a FESCo blocker

+1

+1

-1 until we have more information... I don't see why this has to go rapid and outside the blocker process?

-1 until we have an actual comment from those working on shim and the boot loader. I know two truths about Secure Boot: (a) vendors frequently mess up keys in the firmware and that makes us have to chase down exceptions to ensure we boot out of the box on those systems and (b) when shim does have to be signed by Microsoft, it takes an unknown amount of time that we don't have control over.

I see comments from @pjones on https://bugzilla.redhat.com/show_bug.cgi?id=1883609, so I'm looking at that to see updates on what is happening. I feel we need to understand that before we can make a blocker decision or not. Let's wait for that information.

I suggest setting bug 1883609 aside for now. That bug may or may not be related to the concern raised in this ticket.

The intent of this fesco ticket is to understand and explore the consequences of:

• whether a shim with new-world keys will be included in F33 GA;
• the consequences if F33 ships the current shim with old-world keys;
• when wide-scale revocation of old-world keys will happen (Q1-Q2 2021), i.e. via Windows update;
• whether and how Fedora can reissue Fedora 32/33 images containing new keys.

Indeed there are more questions than answers right now. There isn't a per se bug, hence fesco ticket.

But if it's realistic that F33 will ship with old-world keys, and revocation will happen before either the Fedora 32/33 lifecycles end, we need some contingency even if it's: we're not reissuing images, and UEFI Secure Boot folks will just be out of luck using a current Fedora n-1 release and will have to use Fedora n images that have new keys. Flag day.

• whether a shim with new-world keys will be included in F33 GA;
• the consequences if F33 ships the current shim with old-world keys;

A new shim can be shipped post release, it will affect installers but current users will get the new shim with new-world keys via an update. The installer issue would primarily be a problem if the old-world keys are revoked before F-34 ships with a shim in the installer with the new keys.

• when wide-scale revocation of old-world keys will happen (Q1-Q2 2021), i.e. via Windows update;

A windows update will only affect secure-boot users that dual boot with Windows, or if/when vendors ship firmware updates and the timelines for those.

• whether and how Fedora can reissue Fedora 32/33 images containing new keys.

With a Q1-Q2 timeline it could well be that F-32 is EOL by then.

Indeed there are more questions than answers right now. There isn't a per se bug, hence fesco ticket.

But if it's realistic that F33 will ship with old-world keys, and revocation will happen before either the Fedora 32/33 lifecycles end, we need some contingency even if it's: we're not reissuing images, and UEFI Secure Boot folks will just be out of luck using a current Fedora n-1 release and will have to use Fedora n images that have new keys. Flag day.

For new installs that will be an issue, users running an existing install can always get a new shim via a standard post release update which will allow secure-boot to continue to work as expected.

https://bugzilla.redhat.com/show_bug.cgi?id=1883609#c38
238 revocation entries means something has applied a recent dbx, despite embargo. I don't know whether the dbx can be reliably cleared. A signed dbx means "these keys are revoked" and it is kindof silly to have a local way to circumvent that. But this is firmware and it's bleak territory.

The pertinent timing questions aren't known still. But it might be useful if FESCo starts looking at contingency, i.e. reissuing media once keys are available, if they don't ship in Fedora 33, what that would look like, what the possible problem areas may be.

AGREED: FESCo considers this serious enough to warrant being a blocker, though the resolution does not necessarily have to be technical. (+7, 0, -0)

https://meetbot.fedoraproject.org/fedora-meeting-2/2020-10-07/fesco.2020-10-07-14.00.html

Announced with meeting minutes

Re-opening because we need to revisit the issue. Apparently the scope of the problem is smaller than initially thought, getting a shim update might take longer than anticipated, and reproducing the issue is not easy.

For context: https://bugzilla.redhat.com/show_bug.cgi?id=1883609

Just posted a bug comment with a status update from Peter.

So, at @bcotton 's suggestion, to provide flexibility in handling this bug, yesterday we built a candidate compose that has all known blocker fixes except this one. We will test this compose as if it was an RC, aiming for full test coverage by Thursday. If that doesn't turn up any new blockers, during Thursday's Go/No-Go meeting we will have the option of deciding not to block the release on this after all, and shipping that candidate. It seems to me that since this bug was declared a blocker by FESCo, it's logical that only FESCo can change its mind and say it's not a blocker any more - we can't have the normal blocker process stakeholders vote on it at the meeting as it's not a criteria blocker. So we would need FESCo to make that decision, either ahead of time or by having a FESCo quorum present at the meeting.

So we would need FESCo to make that decision, either ahead of time or by having a FESCo quorum present at the meeting.

For the record, we anticipated this possibility at our last meeting and established a rule:

AGREED: In the event that fewer than a quorum of FESCo members is present at Go/No-Go, a FESCo blocker may only be waived by a unanimous vote of those members present. (+5, 0, -0) (sgallagh, 15:09:17)

We discussed this during today's meeting.

The Proposal to have the f33 release slip until a fixed and resigned shim is available was rejected with (+3, 0, -5), hence we no longer consider the issue a FESCo blocker.

For the record, this was a rather questionable answer:

14:56:15 <decathorpe> Just to clarify: What's the latest point at which we could include a shim update as Freeze Exception before the media for the GA gets generated?
14:56:23 <Eighth_Doctor> Friday

@kevin 's was better, but still a bit hair-raising:

14:57:45 <nirik> uh... thursday? unless everyone agrees to hero work
14:58:08 <nirik> we will need to make a new rc, qa will have to test it.

We have never shipped an RC built on a Friday to the best of my recollection, and we shipped one built early on a Thursday morning (US time) only once in a fairly hair-raising situation I wouldn't really want to repeat. As nirik said, just building a compose isn't enough, it needs to be tested. And since we're changing the UEFI bootloader and apparently it won't be as simple as "just have the exact same bits re-signed" but pjones is actually going to need to fix code, we will want to test it across as many UEFI firmwares as we can. I'm not sure it would be a good idea to try and hero rush testing of an RC with a new shim in two hours or something.

Oh, one more thing: as this will be reconsidered under the regular criteria blocker process, FESCo folks who want to register a vote on that decision can do so in the ticket or during the Go/No-Go meeting tomorrow. To vote in the ticket, write ON ITS OWN LINE, WITHOUT ANY OTHER TEXT ON THE LINE either:

FinalBlocker +1

or:

FinalBlocker -1

and your vote will be counted.