3 ms·

I'm curious how shim avoids the issue Microsoft is concerned about. Presumably if the anti-Tivoization clause of GPLv3 would require a Secure Boot signing key t

I'm curious how shim avoids the issue Microsoft is concerned about. Presumably if the anti-Tivoization clause of GPLv3 would require a Secure Boot signing key to be provided on request, it also requires a MOK signing key to be provided on request. The net result, then, seems to be that any arbitrary party can obtain signing keys which allow them to sign arbitrary code which will be booted (indirectly) via Secure Boot. How is that a meaningfully different outcome from the one we would have if Microsoft simply issued signing keys for GPLv3 projects like grub?

Arnavion 3y ago
MS doesn't "issue" signing keys. MS has a signing key that it uses to sign bootloaders, and which is the default key in every UEFI that wants to be able to boot Windows with Secure Boot enabled. (*) Their argument is that if they signed a particular distro's GPL-licensed binary, then the user of that binary can ask for the source to be able to regenerate that binary, and that would require the signing key for completeness to be able to boot that binary. shim is MIT-licensed so that requirement does not apply. (*) To be precise, the key used to sign Windows and the key used to sign the rest are different, but both are enabled by default. That said, in 2022 there was talk about some UEFIs disabling that latter key by default: https://news.ycombinator.com/item?id=32066919 https://news.ycombinator.com/item?id=32066919
cesarb 3y ago
> I'm curious how shim avoids the issue Microsoft is concerned about. IIRC, shim has a way to allow someone physically present to add additional keys which will also by trusted by that instance of shim. That's enough to satisfy the GPL requirements.
- Arnavion 3y ago
  Yes, that is how the MOK enrolment process works. The distro drops its MOK (the one it used to sign the kernel into the distro kernel package) into the ESP. On next boot shim notices the new key and asks the user if they want to enroll it. Similarly if the user wants to enroll additional keys for kernel modules they built themselves or got from somewhere else, they can do the same process.

Arnavion 3y ago

MS doesn't "issue" signing keys. MS has a signing key that it uses to sign bootloaders, and which is the default key in every UEFI that wants to be able to boot Windows with Secure Boot enabled. (*) Their argument is that if they signed a particular distro's GPL-licensed binary, then the user of that binary can ask for the source to be able to regenerate that binary, and that would require the signing key for completeness to be able to boot that binary. shim is MIT-licensed so that requirement does not apply. (*) To be precise, the key used to sign Windows and the key used to sign the rest are different, but both are enabled by default. That said, in 2022 there was talk about some UEFIs disabling that latter key by default: https://news.ycombinator.com/item?id=32066919 https://news.ycombinator.com/item?id=32066919

cesarb 3y ago

> I'm curious how shim avoids the issue Microsoft is concerned about. IIRC, shim has a way to allow someone physically present to add additional keys which will also by trusted by that instance of shim. That's enough to satisfy the GPL requirements.

Arnavion 3y ago
Yes, that is how the MOK enrolment process works. The distro drops its MOK (the one it used to sign the kernel into the distro kernel package) into the ESP. On next boot shim notices the new key and asks the user if they want to enroll it. Similarly if the user wants to enroll additional keys for kernel modules they built themselves or got from somewhere else, they can do the same process.