This is because MSFT lawyers think that if you sign a GPLv3 licensed bootloader like GRUB, you might have a right to compel the developer into handing over their signing keys.
Source: https://techcommunity.microsoft.com/t5/hardware-dev-center/u...
Vendors shipping absolute shit implementation of SecureBoot that don't give the users authority over their own systems are the problem.
Let's revisit this topic in the future to see how many systems actually get patched to revoke these signatures. My guess is that nearly 100% of shipping systems 1 year from now will still have these keys and still boot these vulnerable signed binaries right out of the box.
One might hope that this issue thrusts the theater of Secure Boot into the public discourse, but like most other forms of irrelevant DRM, it will simply remain a hurdle that everyone has to keep jumping over until the end of time.
Microsoft itself has been the _first_ vendor who shipped systems where SecureBoot could neither be disabled nor the whitelist of signatures/keys replaced with your own. This would be _the only_ scenario where the GPLv3 would have anything to say ... if Microsoft were to be also shipping GRUB in that system, which they weren't .
And such scenario is precisely one of those the GPLv3 was designed to impede. So it is most definitely intentional.
There is no one to blame other than Microsoft.
It’s misleading to mention that but not say that you’re referring to Surface RT tablets, which were Microsoft’s equivalent of an iPad ecosystem — only Store apps, OEM OS only, etc. It’s also running a different flavor of Windows on an ARM processor.
Surface Pro devices have always had toggleable & configurable Secure Boot.
> Surface Pro devices have always had toggleable & configurable Secure Boot.
Not at all. While it is true that Secure Boot has been deactivable in the "Pro" family, disabling Secure Boot results in Scary Boot Prompts (TM) (a _permanent_, literal red screen warning during the boot process that would drive most users away). _To this day_, there is no way to install your own Secure Boot keys in the Surface UEFI setup. Again, one of the "shitty" implementations, and comes from Microsoft!
It's actually worse than that. At least the first two Surface Pro iterations didn't even ship with the UEFI CA key, meaning you could not even install MS-signed Linux distros! The only way would be to disable Secure Boot, and thus have to suffer the red Scary Boot Prompts (TM) on every boot prompt. Again, MS leading the way for the other OEMs in terms of shittiness.
Almost two years afterwards, MS started shipping a WMI-based method that would allow you to install the MS UEFI CA. So you had to install Windows and run a Windows program in order to be able to install an OS signed with your own keys. This is _still true_ even in the latest iteration of Surface Pro devices. This is the example that MS sets for other OEMs.
And almost 10 years later, Lenovo starts disabling the UEFI MS CA key by default....
In the same manner, insane DRM schemes are not made to be solid and unbreakable, or because sellers are worried about home copies (made by people who won't buy the product anyway otherwise). DRM is just a convoluted enough mesaure to protect corporations from their fellow corporations who would gladly make the same thing, but more convenient, or cheaper, or more profitable, and ride the “piracy” wave. In the same manner, Google didn't shove HTTPS into everything because it was worried about the users, but because it was worried about other companies with massive traffic spying abilities grabbing the data Google collected for itself. Et cetera, et cetera.
I don't get what is different between signing workflows that OSS has used for decades and this?
Suppose I write some GPLv3 code. You incorporate that code into a program called shim-gpl3 and release the result under the GPLv3. You also release a binary. Microsoft signs that binary and releases the signature but does not redistribute the binary. Microsoft says that they don’t think that the signature is a copyrightable work but that, to the extent that it is, it is permissively licensed (CC0, MIT, whatever). A Linux distribution builds an installer that contains, shim-gpl3 and Microsoft’s signature. The recipient of the distribution asks the distributor for source to the GPL v3 parts of their distro.
The problem (as I see it) is that the distributor cannot comply. This is as intended! The media, as is, runs on an effectively TiVo-ized machine, and neither the distributor nor the end-user can build it from source such that the result works if modifications are applied.
Now, it seems what you are implying is that they need a new signature that must be created at build time. I'm asking for a much more restrictive bootloader that would have to be buildable with a repeatable process so that someone else can create the same one down to the bit level. Is this as useful as one that is not as restricted? No, but it would be a way past the legal problem?
Reproducible builds are fantastic. But I doubt that, in this instance, it would be a valid way around the GPL.
Maybe if one, as an art project, made a project that, when compiled, had a particularly aesthetically pleasing binary representation, it would be okay. But we’re talking specifically about a signature needed to run the software, which appears to fit the definition of “Installation Information” in section 6 of the GPLv3.
Note that this is VERY limited in how much it could possibly help. But I don't see why it wouldn't be permissible by all licenses involved. It doesn't require the signing key, but a valid signature. For that device, it is locked down enough that the only installer that can work is the one that matches this signature. If installing somewhere else, you don't need the signature anymore, and can make your own or use an unsigned loader.
Thus from Microsoft's point of view all is well.
[0] - https://techcommunity.microsoft.com/t5/windows-os-platform-b...
Microsoft are responsible for pushing secure boot on PCs in the first place. They are absolutely to blame for all problems it causes for regular users that did not explicitly seek a computer with secure boot.
> Vendors shipping absolute shit implementation of SecureBoot that don't give the users authority over their own systems are the problem.
How convenient for Microsoft.
v3 adds an additional requirement that if you mere-aggregate GPL software and other software, and put the aggregate into a consumer product, you can't disable the other software because the GPL software was modified. I don't believe this would apply in the situation that these shims are intended for - i.e. installing an OS onto a desktop machine, as those are supposed to allow you to enroll new Secure Boot keys anyway.
I also don't understand why a signature from Microsoft would actually trip any of the above-mentioned requirements. Microsoft is not distributing the software, they're just signing it - i.e. distributing a message saying "this shim with this hash can run". That's not a copyright violation, so the GPL doesn't come into play at all.
Perhaps there's something else Microsoft does with their signatures that might trip GPL...
As usual it's just FUD.
That seems to be a ridiculous interpretation of the GPL (no personal offense meant, I'm sure you're a fine person but this idea is genuinely very silly).
Signatures on binaries are not part of the source code, and therefore the GPL isn't concerned with them.
Think of:
- every signed binary for an open source app on a Linux distro or Windows install
- Every open source web app delivered over a TLS cert
Nobody has ever considered that the private keys used to sign the package, executable or web site cert to be required by the GPL.
IIRC the GPL concerns itself with buildscripts etc. and GPLv3 was written with the tivoization of v2 in mind.
https://www.gnu.org/licenses/quick-guide-gplv3.html
>Protecting Your Right to Tinker
>Tivoization is a dangerous attempt to curtail users' freedom: the right to modify your software will become meaningless if none of your computers let you do it. GPLv3 stops tivoization by requiring the distributor to provide you with whatever information or data is necessary to install modified software on the device. This may be as simple as a set of instructions, or it may include special data such as cryptographic keys or information about how to bypass an integrity check in the hardware. It will depend on how the hardware was designed—but no matter what information you need, you must be able to get it.
>This requirement is limited in scope. Distributors are still allowed to use cryptographic keys for any purpose, and they'll only be required to disclose a key if you need it to modify GPLed software on the device they gave you.
It does according to MSFT lawyers: https://techcommunity.microsoft.com/t5/hardware-dev-center/u...
There's nowhere in the GPLv3 that says that (then again, that sentence doesn't imply there is). Anyone can download and modify the grub source code, and compile it. It doesn't mean Microsoft is obliged to sign their fork. I wonder if there's something that confused (or was bad faith interpreted) by Microsoft's lawyers?
Maybe someone can just use another open source license? Ie, anything not called 'GPLv3' which, like every other OSS license, does not purport to give someone the right to demand authorization keys to be able to install modified forms of the code on a device.
It does, commonly called the anti-tivoization clause. Here's the text:
> “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
> If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
> The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.
> Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
From GPLv3, section 6. Conveying Non-Source Forms.
From what I understand, allowing the user to install their own trusted keys is enough; there's no need to allow users to sign with the "official" trusted key as long as that alternative exists.
I suspect that Microsoft's worry is that they don't control the firmware (the motherboard manufacturers do), and some UEFI firmware might be broken and not allow installing alternative trusted keys. I believe shim solves this by adding an intermediate layer which also allows the user to manually install their own trusted keys, even if the firmware doesn't.
> “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
> If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
I believe the MSFT lawyers are right here, but obviously I'm not a lawyer.
I now think I was wrong earlier.
Summarizing https://www.gnu.org/licenses/gpl-3.0.html:
> The information (ie 'methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work') must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
The purpose of allowing signing is exactly to ensure modified code does not function in that environment.
Yes MS (and you) would be right. GPLv2, BSD or MIT would be fine but GPLv3 would not.
-----------------------------------
Edit reply to baobun (rate limit means I can't post)
I did think about that, but:
> continued functioning of the modified object code
is vague. Does it mean a new firmware binary should continue working on the same device as the unmodified predecessor or using is a new device (that allows arbitrary entities to sign) considered to be "continued functioning"?
> GPLv2 assures, to the purchaser of an embedded product, their absolute right to receive the information necessary to install a modified version of the GPLv2'd works. [...] installation of the GPL'd works must succeed and operate in a useful and functional fashion on the device.
I believe the FSF position is different, but it's unclear. At least one member of the SFC who was a member of the FSF in the past (Bradley Kuhn) [1] believes that the FSF has the same position - that both GPLv2 software and GPLv3 software must be accompanied by full instructions (and ability) for a user to install their own modified versions on any hardware containing this software. He believes that the only difference with GPLv3 is that, in addition to this requirement, other proprietary software on the device must continue to operate just as before; whereas, with the GPLv2, it's fine for other proprietary software to say "you're running an unsigned version of Linux, failing to start". Linus Torvalds' public statements about the GPLv3, as well as the FSF page on Tivoization [2], seem to suggest otherwise.
Either way, this is not some invention of MS lawyers meant to make the GPL look scarier, it is very much how the free software community sees the GPL working.
[0] https://sfconservancy.org/blog/2021/mar/25/install-gplv2/
[1] https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t...
If I buy a laptop from Lenovo, and it uses a signed GPLv3 bootloader, and I want to modify and run a new version of that bootloader, I'm prevented by the lack of a signature. That action is exactly what the license demands Lenovo permit.
Now, obviously this collides badly with the security requirements of the system. So it's likewise totally reasonable to imagine a court flipping the other way and refusing to literally enforce the GPLv3 because of the potential damage to the market. But if that happens, then what gives Lenovo any right to ship that GPLv3 software at all? Now they're subject to the bootloader authors demanding they stop shipment of the infringing product.
No, the permissively-licensed shim compromise was the right choice.
Why? Why on earth?
IF Lenovo wanted to really ship a GPLv3 bootloader, all it imposes on Lenovo is they ship a method to install your own bootloader keys. Do you really disagree with that?
Lenovo has already shipped hardware which requires magical incantations to install anything other than Windows (see Secured Core hardware). Why on earth anyone shipping FLOSS software would drop their pants to allow precisely this shitshow is over me.