From Newsgroup: comp.misc

If I understand this article right <https://www.tomshardware.com/tech-industry/cyber-security/microsoft-signing-key-required-for-secure-boot-uefi-bootloader-expires-in-september-which-could-be-problematic-for-linux-users>,
there is a signing key stored in the flash RAM of PCs, issued by
Microsoft, which is used to sign a “shim” that allows third-party
Linux distros to boot. However, that key is due to expire this
September.

Microsoft issued an updated key two years ago, but that key may not be
widely installed as yet. This leaves it up to PC/OEM vendors to issue
updates to the flash RAM on their motherboards, which is not something
that can be taken for granted.

I’m not the only one wondering whether Secure Boot is worth the hassle:

It's easy to see the appeal of Secure Boot—making it more
difficult to install bootkits should be a net positive. However,
the looming hassle of dealing with this expiring key is just the
latest in a series of frustrations that encourage people to either
stick with Windows or disable Secure Boot entirely. Right now,
many people opt for the former, but will that continue to be the
case as the popularity of other platforms rises ahead of Windows
10's demise? And is Secure Boot, as it currently exists, prepared
for that shift?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

My computer is so old it doesn’t even have the now mandatory government backdoor.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

If I understand this article right <https://www.tomshardware.com/tech-industry/cyber-security/microsoft-signing-key-required-for-secure-boot-uefi-bootloader-expires-in-september-which-could-be-problematic-for-linux-users>,
there is a signing key stored in the flash RAM of PCs, issued by
Microsoft, which is used to sign a “shim” that allows third-party
Linux distros to boot. However, that key is due to expire this
September.

https://fwupd.github.io/libfwupdplugin/uefi-db.html has a fairly clear technical explanation, including the impact:

1) Existing devices will continue to boot existing installs.
(So we shouldn’t be panicing about devices failing to boot.)

2) Existing devices will be unable to accept updates to their boot chain
after the certificate expires (until the new certificate is
installed). Boot chain updates are rare, but they do happen.

3) Newer devices (with only the new certificate) will be unable to boot
existing install media (signed only with the old key). e.g. you may
struggle to install Ubuntu 14.04 on a laptop released in 2026.
I would expect that platforms still in support (e.g. LTS releases)
will be re-signed with the new key.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Fri, 25 Jul 2025 09:12:41 +0100, Richard Kettlewell wrote:

1) Existing devices will continue to boot existing installs.
(So we shouldn’t be panicing about devices failing to boot.)

One of the key things regularly trumpeted about Linux is about its ability
to give new life to old machines.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In comp.misc, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

One of the key things regularly trumpeted about Linux is about its ability to give new life to old machines.

Disabling secure boot is an option in many, if not most, devices. I have
done it many times, even on a Surface tablet.

Not all distros have signed loaders, so if you do need to use the secure
boot, you could be locked in to one of the big names.

The only real use case for secure boot is part of defense in depth from
someone who can get physical access to machine. Or to try to lock owners
out of their hardware, but who would do that?

Elijah
------
glares at cellphones
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Eli the Bearded <*@eli.users.panix.com> writes:

In comp.misc, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

One of the key things regularly trumpeted about Linux is about its
ability to give new life to old machines.

Disabling secure boot is an option in many, if not most, devices. I have
done it many times, even on a Surface tablet.

The page linked earlier also discusses firmware updates, either direct
from vendors or via LVFS, which AFAICT would address the old devices
issue without compromising security, although I can’t see that stated explicitly.

The <1% devices where it doesn’t work will presumably have to disable
Secure Boot, yes.

Not all distros have signed loaders, so if you do need to use the
secure boot, you could be locked in to one of the big names.

The only real use case for secure boot is part of defense in depth
from someone who can get physical access to machine. Or to try to lock
owners out of their hardware, but who would do that?

It’s valuable (when combined with FDE) to anyone at risk of device theft
or insider threat, which means anyone with a phone or laptop, and any nontrivial organization.

Installing Linux on an obsolete PC is a niche use case, just one that
happens to be well-represented in Usenet.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Eli the Bearded <*@eli.users.panix.com> wrote:

In comp.misc, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

One of the key things regularly trumpeted about Linux is about its
ability to give new life to old machines.

The only real use case for secure boot is part of defense in depth
from someone who can get physical access to machine. Or to try to
lock owners out of their hardware, but who would do that?

It has a second use case. It prevents malware from installing itself
into the firmware boot chain and becoming as a result almost impossible
to clear from the machine.

Of course, this also assumes an owner who does not answer "yes" to
every dialog box that pops up just to make the dialog box go away. The
human in the loop is almost always the weak link in any security
protocol.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 26 Jul 2025 09:09:24 +0100, Richard Kettlewell wrote:

Installing Linux on an obsolete PC is a niche use case ...

Or maybe not, given Microsoft is leaving hordes of Windows 10 users stuck between an upcoming rock and a hard place ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Richard Kettlewell wrote:

Installing Linux on an obsolete PC is a niche use case ...

Or maybe not, given Microsoft is leaving hordes of Windows 10 users
stuck between an upcoming rock and a hard place ...

It wouldn’t be a bad use of the old hardware. But the same applied to
earlier versions of Windows and didn’t lead to a mass migration to
Linux, so I think you’re just engaging in wishful thinking here.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Fri, 25 Jul 2025 09:12:41 +0100, Richard Kettlewell wrote:

1) Existing devices will continue to boot existing installs.
(So we shouldn’t be panicing about devices failing to boot.)

One of the key things regularly trumpeted about Linux is about its ability >to give new life to old machines.

And it does. I believe this should not matter if you have secure boot disabled. If you don't have device encryption enabled, then secure boot
is useless anyway.... and if you do have device encryption enabled you
have a roadmap to deal with this (which may mean buying a new machine
or setting the bios date back, etc.)
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 27 Jul 2025 09:33:58 +0100, Richard Kettlewell wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

Richard Kettlewell wrote:

Installing Linux on an obsolete PC is a niche use case ...

Or maybe not, given Microsoft is leaving hordes of Windows 10 users
stuck between an upcoming rock and a hard place ...

But the same applied to earlier versions of Windows ...

Not to this scale.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

kludge@panix.com (Scott Dorsey) writes:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Fri, 25 Jul 2025 09:12:41 +0100, Richard Kettlewell wrote:

1) Existing devices will continue to boot existing installs.
(So we shouldn’t be panicing about devices failing to boot.)

One of the key things regularly trumpeted about Linux is about its ability >>to give new life to old machines.

And it does. I believe this should not matter if you have secure boot disabled. If you don't have device encryption enabled, then secure boot
is useless anyway.... and if you do have device encryption enabled you
have a roadmap to deal with this (which may mean buying a new machine
or setting the bios date back, etc.)
--scott

I checked with my favourite AI which agreed with you, saying that
malware can get into firmware or in through other weaknesses. But I
wonder why encryption would prevent that, as if malware got in through
ssh or through a web browser, then the disk would be decrypted in the
same way as for a legitimate user.

"If you don't have device encryption enabled, an attacker who gains
physical access to your device can bypass the secure boot process and
install malicious firmware or operating system components."

"Even without physical access, an attacker can still bypass secure boot
if device encryption is not enabled. They can exploit vulnerabilities in
the firmware or operating system to bypass secure boot and gain access
to the system."

"You're pointing out a valid concern. Encryption alone doesn't provide a significant security benefit in this scenario. If an attacker gains
access to the system through a vulnerability, they can still access the encrypted data. The encryption is primarily designed to protect against physical access to the device, not against network-based attacks.

In the case of a network-based attack, the encryption is not a
significant barrier because the attacker can still access the system and decrypt the data using the same credentials as a legitimate user. Device encryption is more of a barrier against physical theft or unauthorized
access to the device itself."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <86h5ywi9q3.fsf@example.com>, Richmond <dnomhcir@gmx.com> wrote:

I checked with my favourite AI which agreed with you, saying that
malware can get into firmware or in through other weaknesses. But I
wonder why encryption would prevent that, as if malware got in through
ssh or through a web browser, then the disk would be decrypted in the
same way as for a legitimate user.

Your favorite AI is missing some of the point.

If you have device encryption enabled, then when your laptop is stolen
from your car or house the bad guys won't be able to read what is on
the disk.

Whether or not secure boot is enabled, they won't be able to read what
is on the disk. So disk encryption is actually useful in some
applications.

Secure boot will prevent the system from booting without a boot password,
so without the boot password they won't be able to boot the machine and
try to guess your login password. It's really just a matter of passwording
the machine as well as the disk and it's not really that useful.

Secure boot will in fact prevent bad people with physical access from
making changes to the bios firmware, but that is a relatively small risk. --scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2025-07-28, Scott Dorsey <kludge@panix.com> wrote:

Secure boot will prevent the system from booting without a boot password,
so without the boot password they won't be able to boot the machine and
try to guess your login password. It's really just a matter of passwording the machine as well as the disk and it's not really that useful.

The point of "secure boot" is to prevent the possessor[1] of the machine
from booting software not authorised by the licensor[2]. A boot (bios) password, and full-disc encryption, are orthogonal to "secure boot".

Secure boot will in fact prevent bad people with physical access from
making changes to the bios firmware, but that is a relatively small risk.

Not if they can flash the BIOS some other way (JTAG, hardware swap etc.)


[1] Be that the legal owner of the hardware or a thief.

[2] aka Microsoft, it seems.
--
Ian

"Tamahome!!!" - "Miaka!!!"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Richard Kettlewell <invalid@invalid.invalid> writes:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

If I understand this article right
<https://www.tomshardware.com/tech-industry/cyber-security/microsoft-signing-key-required-for-secure-boot-uefi-bootloader-expires-in-september-which-could-be-problematic-for-linux-users>,
there is a signing key stored in the flash RAM of PCs, issued by
Microsoft, which is used to sign a “shim” that allows third-party
Linux distros to boot. However, that key is due to expire this
September.

One detail: nothing is expiring this September. The expiry dates in the certificates are in 2026, and UEFI firmware generally ignores expiry
dates in certificates[1] anyway. The thing that actually happens soon is
the switch to signing with the new key; the fallout is that devices that
only trust the old key will not be able to accept code signed only with
the new key.

[1] Keys as such do not (normally) have expiry dates. Certificates (or
some kinds of certificate) do.

https://fwupd.github.io/libfwupdplugin/uefi-db.html has a fairly clear technical explanation, including the impact:

1) Existing devices will continue to boot existing installs.
(So we shouldn’t be panicing about devices failing to boot.)

2) Existing devices will be unable to accept updates to their boot chain
after the certificate expires (until the new certificate is
installed). Boot chain updates are rare, but they do happen.

3) Newer devices (with only the new certificate) will be unable to boot
existing install media (signed only with the old key). e.g. you may
struggle to install Ubuntu 14.04 on a laptop released in 2026.
I would expect that platforms still in support (e.g. LTS releases)
will be re-signed with the new key.

Matthew Garret has also written about this at https://mjg59.dreamwidth.org/72892.html. The TLDR is:

Conclusion: Outside some corner cases, the worst case is you might
need to boot an old Linux to update your trusted keys to be able to
install a new Linux, and no computer currently running Linux will
break in any way whatsoever.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.21a-Linux NewsLink 1.2