This also does not mean that GPLv3 makes software signing impossible and that you must forbid users from rejecting unsigned software if they so wish. It doesn't mean that you have to distribute every secret key that you use for signing software. It merely means that you have to give your users a way to install software on the User Product as they see fit, if they see fit. It's up to the user to decide to override any signing feature or not. It's very much in spirit with GPLv2 that required installation scripts. As far as GPLv3, hardware signing keys are just another part of installation scripts (the actual term used in GPLv3 is "Installation Information").
http://radar.oreilly.com/2007/03/gplv3-user-products-clause....
https://copyleft.org/guide/comprehensive-gpl-guidech10.html#...
Also don't forget the patent stuff in GPLv3. That's not quite as scary as the anti-TiVoization stuff, but it's still pretty significant for large companies.
I think that's wrong: http://www.gnu.org/licenses/gpl-faq.en.html#GiveUpKeys:
> I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3 forces me to release my private signing keys? (#GiveUpKeys)
> No. The only time you would be required to release signing keys is if you conveyed GPLed software inside a User Product, and its hardware checked the software for a valid cryptographic signature before it would function. In that specific case, you would be required to provide anyone who owned the device, on demand, with the key to sign and install modified software on his device so that it will run. If each instance of the device uses a different key, then you need only give each purchaser the key for his instance.
It sounds like a manufacturer could ship a GPLv3-compliant User Product with two signing keys: a secret one known only to the manufacturer, and a second per-device key than can be used by the end-user to install modified software. Such a manufacturer wouldn't be forced to disclose their signing key because the user already has access to an equivalent.
I also imagine it would be kosher for the device to provide the user the option, in the name of security, to permanently clear the second per-device key, so only manufacturer updates can ever be installed.
> companies like Apple won't even allow employees to install GPLv3 software on their work computer because if a single piece of GPLv3-licensed code makes it into iOS, even completely accidentally, the license demands that Apple release their root signing keys to the world, completely destroying the security of hundreds of millions of devices.
If Apple is behaving that way, it's Apple's own fault, not the GPLv3's. They could have chosen to design their software in a way that would have given them better options if they are ever forced to comply with the GPLv3, but they chose not to.
> If Apple is behaving that way, it's Apple's own fault, not the GPLv3's. They could have chosen to design their software in a way that would have given them better options if they are ever forced to comply with the GPLv3, but they chose not to.
That makes no sense. What you said is basically equivalent to "That's Apple's fault, they could have just designed their hardware platform to be completely insecure".
GPLv3 is fundamentally incompatible with having a secure hardware platform. This is absolutely GPLv3's fault.
How so? It's a solved problem. Don't smartphones already have numerous device-specific identifiers and keys loaded to them? All they would really need to do is slap an extra sticker on the device with the device-specific key printed on it. For instance, my phone came with a sticker with its IMEI printed on it.
The IMEI example was just to demonstrate the ability to slap a device-unique code + matching sticker on something during manufacturing at scale.
This is a surprisingly common oversight that the hardware freedom crowd keeps ignoring. I don't understand why so many people just implicitly assume that physical access means security should be thrown out the window.
That's funny because Chromebooks ship with GPLv3 code.
If you've a mind to, you can put the Chromebook in "developer mode" with a magic sequence of commands (requiring physical access as it's a boot procedure). This gives you root. To protect naive users from being exploited, a Chromebook in developer mode will display a nasty warning on boot. This warning lingers on the screen for an annoying amount of time, accompanied by a beep. The only way (and it's undocumented) of skipping the wait and the beep is with Ctrl-D; pressing any other key while on this screen results in the Chromebook being completely reset. All this is to ensure that it's virtually impossible to run under developer mode unintentionally.
If all this gets too annoying and you want to use the Chromebook as a fully general device, you can blow it away by replacing the bootloader. Doing this requires disabling write-protection on the flash, which requires opening the case.
Disclaimer: I own a Samsung ARM Chromebook. For all I know the precise details may vary across the Chromebook line, though I believe they all work similarly. Fuller details are here: https://www.chromium.org/chromium-os/developer-information-f...
That's easily solved: On initial device setup, the user could be asked to explicitly disable the key by asking something like "Would you like to secure your device by permanently disallowing the installation of untrusted software? Y/N"
Also, as someone else clarified below, the alternate key I was proposing is unique to the device. So any attack against you would have to be tailored to your device. That leaves the main threats as: 1) an NSA-like shipment-interception and 2) someone getting access to your user key after the device is in your possession. 1) can be mitigated by buying your device in a random retail shop, and 2) can be prevented by immediately permanently clearing the user the key.
For example, can the user change their own key? If yes, the device can never be trusted second-hand - the OS might have been modified to secretly accept more keys. If no, then the device also can never be trusted second-hand - the previous owner could well have retained the key. And which key is superior, the manufacturer key or the user key? Can the possessor of a key override actions attempted using the other key?
Also, as written, this is just a bad solution. So you ask the user on initial setup. Let's say 99% of users won't know what the question is asking. So maybe they hit "yes", and now we're just back to iPhones and no user freedom, for them or any subsequent device owners. Or maybe they hit "no", and now they're no more secure and there was really no point in asking them. Maybe it's a 50-50 split, depending on how they feel (and not related to how they would choose given informed consent). Or maybe the user is informed, in which case they are very likely to just hit "no", if for no other reason than to preserve the resale value.
Don't get me wrong, I do think this could be done right. But attempting to guarantee "security" (that is, the dubious sort of security that is manufacturer-only updates) to naive users, freedom to power users, and preserve those guarantees as the device changes hands... well, that's a Hard Problem. I think only Chromebooks have attempted it so far.
That's always going to be a risk with second-hand devices (or even new devices). Who knows what kind sneaky things someone did to a device that they had long-term access to. You can never really totally trust something that you didn't build yourself from the ground up, so you always have to accept some level of risk.
That UI solution was just a random idea, I'm sure there are better ones. Like you said, it's a Hard Problem.
It's pointless anyway trying to "secure" hardware against a sufficiently determined attacker with physical access. There's an argument to be made that physical access should equal software ownership, philosophically.
It's also worth noting that requiring all updates to be signed by the manufacturer does not protect you from malicious code, as manufacturer updates can also be malicious. Ultimately, the "owner" of the device should be at the top of the pyramid of trust.
The Apache license has a nearly identical clause (in fact, I believe GPLv3 was inspired from the Apache license) and companies like Google and Apple have used the Apache license without destroying their business. Anti-retaliation clauses don't seem to be a death knell.
http://en.swpat.org/wiki/Patent_clauses_in_software_licences...
Oh please. It really doesn't, it merely mandates that the user is able to override a manufacturer's lockdown. Not that any nitwit should be able to override a user's lockdown.
It solidifies the freedoms the FSF champions.
There's two issues at play with copyleft licenses. The first is making the source available to others, and the second is allowing others to install modified versions of the software. GPLv3 mandates both. GPLv2 was certainly intended to mandate both, but ends up mostly just mandating the first. If all you care about is having other people who use your software release the source to their modified versions, then GPLv2 is clearly superior to GPLv3 because it has fewer restrictions. Similarly, if you care about having source made available but you also want to have your software become as popular as possible, you may opt for GPLv2 because it's a lot more likely for companies to use your software than if it's GPLv3.
By your "fewer restrictions" logic, permissive licenses would be the ones most copyleft. Again, the purpose of copyleft is proliferating "freedom-respecting" software, not amassing - open source. Code that is open, but you can't utilize freely because of a locked-down device or a patent - "misses the point". Preceding references emerged organically and... whoa.
Most GPLv2 bias which isn't caused by Linux' licensing is due to the kind of FUD you've perpetuated in this thread, not any actual issue with GPLv3.
Please don't strawman me. I already explained how there's two different freedoms that copyleft licenses seek to protect, and it's perfectly valid for someone to care only about the first freedom but not the second, and for such a person the GPLv2 is superior.
> Most GPLv2 bias which isn't caused by Linux' licensing is due to the kind of FUD you've perpetuated in this thread, not any actual issue with GPLv3.
Contrary to what you may believe, FUD is not defined as "any opinion you disagree with". And by calling my arguments FUD instead of actually trying to address the points I made, you're just telling me that you can't actually argue against what I said so you'd rather try and discredit me.