3 ms·

I'm a strong advocate of open source who also happens to agree with microsoft's lawyers on this. Whether you believe this consequence of GPLv3 is intentional or

I'm a strong advocate of open source who also happens to agree with microsoft's lawyers on this. Whether you believe this consequence of GPLv3 is intentional or unintentional, it is a consequence. The idea of somehow putting blame back on Microsoft for this is similarly twisted. 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.

ogurechny 3y ago
You seem to still have an impression that “secure” here is somehow related to “security” of the users or their “authority over their own systems”, when in fact it only means “securing” the position of the company that gets to control the thing. Even if Microsoft fires everyone tomorrow and closes, Secure Boot key infrastructure and agreements will still cost a lot. Just like patent pools of former industrial giants that don't just disappear. 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.
pjmlp 3y ago
Even on Azure, GNU/Linux runs on top of Windows based hypervisor (Cloud Host[0]), and WSL is a VM anyway. Thus from Microsoft's point of view all is well. [0] - https://techcommunity.microsoft.com/t5/windows-os-platform-blog/azure-host-os-cloud-host/ba-p/3709528 https://techcommunity.microsoft.com/t5/windows-os-platform-b...
account42 3y ago
> The idea of somehow putting blame back on Microsoft for this is similarly twisted. 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.
SahAssar 3y ago
Wouldn't it be the same scenario as if I sign a release binary with a GPG key, or even sign a commit with GPL code with a GPG key? I don't get what is different between signing workflows that OSS has used for decades and this?
- AshamedCaptain 3y ago
  The difference starts when the _right_ signature is required to continue using the software, preventing you from effectively modifying the software.
  - taeric 3y ago
    Couldn't they release a signature separate from the thing they signed? Leaving it as work that the open source world has to do to combine them into the derivative work? Surely an attestation/signature would be a fair use derivative work?
    - amluto 3y ago
      Would it? 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.
      - taeric 3y ago
        If I publicly attest to something, and provide cryptographic proof that you can verify the version you are looking at is the one that I attest to, then I do not see how that is meaningfully a derivative work of what we are attesting. It is not substantial enough in size or form for it to be a derivative work. So, from that end, it seems we agree that the signature itself is not a problem. 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?
AshamedCaptain 3y ago
> Vendors shipping absolute shit implementation of SecureBoot that don't give the users authority over their own systems are the problem. 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.
- smileybarry 3y ago
  > 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. 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.
  - AshamedCaptain 3y ago
    Why misleading? It shows exactly what the long-term MS strategy was, what SecureBoot was designed for, and it also shows exactly who shipped the first "shitty" SecureBoot implementation. People had to resort to cracks in order to run plain Win32 apps! Except, of course, Office. That one is the only Win32 app which was allowed. Good ol', classy Microsoft. > 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....

ogurechny 3y ago

You seem to still have an impression that “secure” here is somehow related to “security” of the users or their “authority over their own systems”, when in fact it only means “securing” the position of the company that gets to control the thing. Even if Microsoft fires everyone tomorrow and closes, Secure Boot key infrastructure and agreements will still cost a lot. Just like patent pools of former industrial giants that don't just disappear. 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.

pjmlp 3y ago

Even on Azure, GNU/Linux runs on top of Windows based hypervisor (Cloud Host[0]), and WSL is a VM anyway. Thus from Microsoft's point of view all is well. [0] - https://techcommunity.microsoft.com/t5/windows-os-platform-blog/azure-host-os-cloud-host/ba-p/3709528 https://techcommunity.microsoft.com/t5/windows-os-platform-b...

account42 3y ago

> The idea of somehow putting blame back on Microsoft for this is similarly twisted. 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.

SahAssar 3y ago

Wouldn't it be the same scenario as if I sign a release binary with a GPG key, or even sign a commit with GPL code with a GPG key? I don't get what is different between signing workflows that OSS has used for decades and this?

AshamedCaptain 3y ago
The difference starts when the _right_ signature is required to continue using the software, preventing you from effectively modifying the software.
- taeric 3y ago
  Couldn't they release a signature separate from the thing they signed? Leaving it as work that the open source world has to do to combine them into the derivative work? Surely an attestation/signature would be a fair use derivative work?
  - amluto 3y ago
    Would it? 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.
    - taeric 3y ago
      If I publicly attest to something, and provide cryptographic proof that you can verify the version you are looking at is the one that I attest to, then I do not see how that is meaningfully a derivative work of what we are attesting. It is not substantial enough in size or form for it to be a derivative work. So, from that end, it seems we agree that the signature itself is not a problem. 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?

AshamedCaptain 3y ago

> Vendors shipping absolute shit implementation of SecureBoot that don't give the users authority over their own systems are the problem. 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.

smileybarry 3y ago
> 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. 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.
- AshamedCaptain 3y ago
  Why misleading? It shows exactly what the long-term MS strategy was, what SecureBoot was designed for, and it also shows exactly who shipped the first "shitty" SecureBoot implementation. People had to resort to cracks in order to run plain Win32 apps! Except, of course, Office. That one is the only Win32 app which was allowed. Good ol', classy Microsoft. > 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....