> It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead.
But you don't have to do two different systems. You can use the exact same update mechanism, just with the cryptographic validation controlled by the owner of the hardware.
Look at how Secure Boot is implemented on most x86 platforms. Default installed keys from the OEM, can not be changed from the OS, but can be disabled or replaced by the end user.
Chromebooks offer another example of how to do it well with their "Developer Mode" switches. With the switch (which is not accessible on an operating system) in the default position it will only boot Google signed images. With the switch in developer mode it notifies the user of this on every boot, but no longer verifies signatures. The device is factory reset when switching modes to ensure that the unsigned mode can not be used to compromise a stolen device.
Android phones with unlockable bootloaders work similarly, they just have a software toggle in the first-stage bootloader rather than a physical switch.
---
There are plenty of low-effort ways to provide cryptographic verifiability to end users while still following not just the letter but the spirit of the GPL.
Obviously most of us would prefer something like the first example where a user could replace the stock keys with their own and sign their own code to maintain full security when going off on their own, the second and third options are nearly trivial to implement. One switch or jumper, a single input pin, and however much code it takes to check the state of that pin when performing any boot validation.
But you don't have to do two different systems. You can use the exact same update mechanism, just with the cryptographic validation controlled by the owner of the hardware.
Look at how Secure Boot is implemented on most x86 platforms. Default installed keys from the OEM, can not be changed from the OS, but can be disabled or replaced by the end user.
Chromebooks offer another example of how to do it well with their "Developer Mode" switches. With the switch (which is not accessible on an operating system) in the default position it will only boot Google signed images. With the switch in developer mode it notifies the user of this on every boot, but no longer verifies signatures. The device is factory reset when switching modes to ensure that the unsigned mode can not be used to compromise a stolen device.
Android phones with unlockable bootloaders work similarly, they just have a software toggle in the first-stage bootloader rather than a physical switch.
---
There are plenty of low-effort ways to provide cryptographic verifiability to end users while still following not just the letter but the spirit of the GPL.
Obviously most of us would prefer something like the first example where a user could replace the stock keys with their own and sign their own code to maintain full security when going off on their own, the second and third options are nearly trivial to implement. One switch or jumper, a single input pin, and however much code it takes to check the state of that pin when performing any boot validation.