Answering the specific question here...

On Wed, Jul 03, 2024 at 06:21:27PM +0200, Roland Clobus wrote:

To reproduce:
* Use the stock OVMF_VARS_4M.ms.fd
* Boot with the live 12.6.0 bookworm image (I used 'standard') [1] or the >netinst image [2]
* mokutil --list-sbat-revocations shows:
sbat,1,2022052400
grub,2
* Boot with a freshly built live sid image [3]
* mokutil --list-sbat-revocations shows:
sbat,1,2024010900
shim,4
grub,3
grub.debian,4
* Boot with the bookworm image again -> the SBAT error message is shown.

This would mean that any machine that got an SBAT revocation would not be >able to boot the official Debian Bookworm images any more.

Does this mean that it would be necessary to release a set of 12.6.1 images? >(i.e. live, netinst, etc.)

I was hoping to get the new shim-signed packages prepped for the 12.6
and 11.10 builds, but unfortunately the signing process at Microsoft
took too long. I'm planning on adding them shortly so we'll get them
for 12.7 and 11.11 (and buster-security). In the meantime, you'll need
to manage firmware variables if you're switching between sid and
bookworm images.

--
Steve McIntyre, Cambridge, UK. steve@einval.com "Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
characters." -- Ignatios Souvatzis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Steve McIntyre <steve@einval.com> (2024-07-03):

There are other alternative on your test systems:

ACK, ta.

1. disable secure boot while testing (which of course is *not* the
right answer long-term!)

That's BIOS-based tests for me.

2. use mokutil --set-sbat-policy from a running system to go back to
a previous SBAT minimum level, or delete the policy altogether

3. if you're testing in a qemu VM, you can also use "virt-fw-vars"
from the "python3-virt-firmware" package to modify the SBAT (and
other) firmware settings from outside the VM. This is *incredibly*
useful when doing development and CI with shim.

ACK. At least at my level I *really* don't want to be diverging from
what end users are going to face: I really want to know about such
things, and not to publish if we know that's going to explode anyway.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmaFuFQACgkQ/5FK8MKz VSCGaQ//b3cQMZLO29Q90zgvBCYp048RwAkQtlQSndSj8g4ZjiZoRuTXSkGF/9Je F1a2wrrQCfFKs2K38hdRq8zCmeyOh/DjMmWqjIPkg2fSBPIcQf9OPxipyLLdvfX3 84zoDYkkMZJ8DxBTI2GwPU8pGEvwMs82hyBqP4sfCQzxaksvssHET8d3DOOgTsT5 4nIh96o1NVjBLTSL4+3TaIeOyjVhnBEVd2EMfOM08PvedKq2lsh2V8QYS/T2TpPo hk12glMYsLyhliDP9NDeHGD+Titur70B8ezPFE/7xikUyEN6KTOIIeg0/E4UuYLO 4uPzDxfsE3WSIsteFP1QGe/wn/rjV7P1a/0YJm5M5YIWSCy2Cb7rlTU7IRqFBApu VA/Lq4AWW9fqjluOn4qcPR1y/1DvO7BX353WYMp0dL1IVIwGxyCTirKuM12Kup1o KUFbd6YoBVi3JgT5vD3aOI2Ya4On+t/mnPP3anIlGtqf8AU6PR8BOOsrElVUZYSe Pi6v7ItqiZK6zRY/R/KtlUt8d3O6YRT1yWOTKkyHbSRfUDtLTvHUgwWWfrsCXH1y CrgICT1i+MqoLlRPNDfQJy0C909mU/vTT/3Y8r9k+J8fqpWuTPshmxNi+9qgR1jj g7WYHGbjDUH1RWoRT+Zsiz+tTKQDMaIxTqHjU3AzuTc0fZZexj0=
=y/2q
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Wed, Jul 03, 2024 at 10:45:10PM +0200, Cyril Brulebois wrote:

Steve McIntyre <steve@einval.com> (2024-07-03):

There are other alternative on your test systems:

ACK, ta.

1. disable secure boot while testing (which of course is *not* the
right answer long-term!)

That's BIOS-based tests for me.

2. use mokutil --set-sbat-policy from a running system to go back to
a previous SBAT minimum level, or delete the policy altogether

3. if you're testing in a qemu VM, you can also use "virt-fw-vars"
from the "python3-virt-firmware" package to modify the SBAT (and
other) firmware settings from outside the VM. This is *incredibly*
useful when doing development and CI with shim.

ACK. At least at my level I *really* don't want to be diverging from
what end users are going to face: I really want to know about such
things, and not to publish if we know that's going to explode anyway.

Nod. Apologies for the surprise this time. I was hoping to minimise
the pain with quick uploads and migration, but... :-(

--
Steve McIntyre, Cambridge, UK. steve@einval.com "The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow words; on
occasion, English has pursued other languages down alleyways to beat them
unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 03, 2024 at 09:29:11PM +0100, Steve McIntyre wrote:

There are other alternative on your test systems:

1. disable secure boot while testing (which of course is *not* the
right answer long-term!)

2. use mokutil --set-sbat-policy from a running system to go back to
a previous SBAT minimum level, or delete the policy altogether

3. if you're testing in a qemu VM, you can also use "virt-fw-vars"
from the "python3-virt-firmware" package to modify the SBAT (and
other) firmware settings from outside the VM. This is *incredibly*
useful when doing development and CI with shim.

In fact, having tested lots more combinations of things today
(covering all of buster, bullseye, bookworm and unstable), I can say
that #2 above will likely *not* work, in fact. Once we roll out the
updated signed shims for all of the older releases, that will break
secure booting with existing installation and live media. This is not
great, I'll admit.

The updates in older stable releases might cause problems when they
happen, but they'll all hit the archive on the next point release
weekend. At the same point we'll have new media that will boot in SB
with the new settings, so I think this is fine.

The thornier problem is the shim-signed that's in unstable right
now. It hasn't migrated to testing yet (and won't without an unblock
AFAICS), so there is a comparatively limited set of machines with it
installed. I'm *tempted* to revert shim-signed and go back to using
the previous 15.7 shim *for now* there. Then move forward to 15.8
again just before the point release.

How does that sound? Feedback welcome...

--
Steve McIntyre, Cambridge, UK. steve@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 03, 2024 at 09:50:39PM +0100, Steve McIntyre wrote:

Nod. Apologies for the surprise this time. I was hoping to minimise
the pain with quick uploads and migration, but... :-(

Why are the levels not enforced by Debian Breaks/Conflicts as well?

Bastian

--
The face of war has never changed. Surely it is more logical to heal
than to kill.
-- Surak of Vulcan, "The Savage Curtain", stardate 5906.5

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)