18 ms·

This is absolutely a mistake. The whole point of requiring the firmware to be signed with a specific private key is to prevent third parties from installing the

by eridius 11y ago

This is absolutely a mistake. The whole point of requiring the firmware to be signed with a specific private key is to prevent third parties from installing their own custom firmware (e.g. to prevent malicious actors from installing malware onto the device). If you want to let everyone install their own build, then just don't require the code signature (or, alternatively, create a program where third parties can request a certificate signed with your master, so they can then sign their own binaries, similar to how iOS development works). > For every device requiring images to be signed with a specific key, this is exactly what the manufacturer should be forced to release! What do you mean by "should" here? If the source is covered by GPLv3, then yeah, if they use code-signing they need to have some way to let you get around it. That's the point of the anti-tivoization clause. But if the software is distributed under GPLv2, or any other license, then there's no anti-tivoization restriction, and therefore no "should" about it.

mindslight 11y ago
> The whole point of requiring the firmware to be signed with a specific private key is to prevent third parties from installing their own custom firmware Yes, which is blatantly anti-GPL2. I really wish any Linux copyright holder would step up to the plate and force the argument that since code+signature is the functional unit, adding the signature makes a derivative work and its source must be released in the preferred form for modification. The entire point of the GPL2 is that a developer who creates code and receives a modified version back should be able to modify that instance of code - tivoization is entering into the license in bad faith. Of course going GPL3 would make for a more solid foundation for doing so, but clarifying this subject directly conflicts with the desires of the proprietary sponsors - Google etc.
- kinghajj 11y ago
  I was under the impression that while it may be against the spirit in which GPL2 was written, it was an oversight and the necessary changes were made to GPL3.
  - mindslight 11y ago
    As far as I know, it has never been litigated - there is enough work making manufacturers release anything called "source" as it is. People writing new software just go with the clarified GPL3. Based on Linus's views, the Linux kernel being GPL is a happy accident of history. We should be glad it wasn't BSD so we at least ended up with DD-WRT/AOSP/etc. But we also should keep pushing to preserve the freeedoms that fostered it.
  - marcosdumay 11y ago
    The problem is that most people releasing GPLv2 software were not involved at its creation, and are doing it for the bare text contents or completely unrelated reasons. The original goals of the creators are not a very relevant reason. Yes, the GPLv3 fixed that, and there was plenty of time for projects to migrate already. Linux won't migrate, Linus already explicitly stated so.
- eridius 11y ago
  > Yes, which is blatantly anti-GPL2. No it's not. It's anti-GPLv3. GPLv2 absolutely allows tivoization. Stallman thinks this is bad, but not everybody else agrees (I know Linus Torvalds thinks tivoization is fine in the context of GPLv2, and I believe the FSF agrees). > I really wish any Linux copyright holder […] Your argument here is not a legal one. Any Linux copyright holder that did this would lose horribly. And in particular, Linus Torvalds explicitly stated that he does not support relicensing the Linux kernel under GPLv3 because of this (even if it were possible, which it isn't because of the very large number of copyright holders). Source: https://en.wikipedia.org/wiki/Tivoization#GPLv3 https://en.wikipedia.org/wiki/Tivoization#GPLv3 > The entire point of the GPL2 is that a developer who creates code and receives a modified version back should be able to modify that instance of code And they can! But the GPLv2 does not require that the modified code must be able to be installed back on the original hardware by the person doing the modification. > tivoization is entering into the license in bad faith Not by any legal definition of "bad faith", and even with the informal definition, a lot of people would disagree with you.
  - mindslight 11y ago
    > the GPLv2 does not require that the modified code must be able to be installed back on the original hardware by the person doing the modification Does not explicitly. From GPL2: > Accompany it [executable code] with the complete corresponding machine-readable source code ... The source code for a work means the preferred form of the work for making modifications to it So, you're telling me that the preferred form for making modifications to the source code of a router does not include the scripts which install onto the router to test those modifications? > Not by any legal definition of "bad faith" The GPL2 and the FSF are very explicit on what the GPL2 is supposed to engender. Accepting the license and trying to circumvent it on a possible technicality (assertion that a signed blob isn't a derivative work, when the only reason anyone is interested in the source code is to run it) looks pretty bad-faith to me. IANAMOAG (I am not a member of a guild, and you probably aren't either). Even if we were, we could still disagree until it was actually litigated. I see no reason to prematurely capitulate Linux devices being non-Free.
    - 11y ago
- superuser2 11y ago
  Code-signing is a useful and necessary security measure, so long as it is possible for the owner of the device to sign his own code. You need a good way to distinguish between the end-user and someone who has pwned him.
  - mindslight 11y ago
    IMHO a well-documented JTAG, USB, or serial interface on the board to change the trust root would suffice. If you wanted to prevent evil maid attacks, then a time lock would actually be more secure than a fixed trust root with respect to downgrade attacks and leaked keys.
- znfi 11y ago
  Here is Linus discussing GPLv3 and tivoization etc at DebConf 14 in quite some depth http://www.youtube.com/watch?v=5PmHRSeA2c8&t=47m20s http://www.youtube.com/watch?v=5PmHRSeA2c8&t=47m20s (Basicly he doesn't consider tivoization to be that much of an issue, and doesn't consider it to be something he wanted when he selected the GPLv2)
- michaelmior 11y ago
  I think it makes sense to require that any automated firmware updates be signed by the device manufacturer and this this key is never released. This is to protect consumers from malicious third parties who may attempt to install malicious firmware. Then there can either be an option to disable this check or a large warning that is produced when you try to install unsigned code. There's really no point in code signing if everyone has access to the private keys.
  - AnthonyMouse 11y ago
    > Then there can either be an option to disable this check or a large warning that is produced when you try to install unsigned code. If the device allows unsigned or self-signed code to be installed then there would be no need to release the signing keys because they are not necessary to make modifications. Releasing signing keys should only be required when it doesn't.
    - michaelmior 11y ago
      Exactly my point.
  - marssaxman 11y ago
    I think it makes more sense to simply forbid automated firmware updates. Put a physical switch on the box; I'll press it when I want to update the firmware. No crypto signature needed.
    - michaelmior 11y ago
      What about non-technical users who require firmware updates for bug fixes or new features? You can have a physical button, but if the network has been owned in some way, pressing the button could still lead to malicious firmware being installed. I could see this easily coupled with some social engineering. Control the network and then email users saying that an important update is needed.
      - 11y ago
- DannyBee 11y ago
  The GPL is rarely litigated. What you are talking about is not blatantly anti-gplv2 IAAL (and an open source licensing lawyer at that, for many years). I'm also a contributor to FSF projects :) Even I would tell you the GPLv2 almost certainly does not cover code signing. It's actually very epxlicit about what needs to be there: That's the whole problem with gplv2: " For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." That's it. It very clearly and explicitly says what you must include, and installation keys in not there. It even says 'scripts used to control installation", not "scripts involved in installation" or anything like that.
  - deleted 11y ago
    [deleted]
  - mindslight 11y ago
    > What you are talking about is not blatantly anti-gplv2 Someone who buys a router running locked down Linux lacks two out of the four essential freedoms, so yes tivoization is blatantly anti-gpl2. I would say this is a popular (edit: non-legal) opinion, especially given the upvotes I have received. But the legal interpretation may diverge from the spirit and purpose of the license, so I would love to hear the opinions of an experienced lawyer... I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. What exactly would you say that "scripts used to control ... installation" includes? A script that says "cp -f a.out /bin/" most certainly qualifies, no? And how about "st-flash write foo.bin 0x8000000" ? And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? Surely you're not arguing that these scripts "perform" the installation rather than "control" it ?
    - DannyBee 11y ago
      "I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. " So, then we have a problem. Courts assume that drafters who write lists mean something by each member of the list. So they are going to read a definition the differs between controls and installs when they see: " plus the scripts used to control compilation and installation of the executable" IE they will read a definition that means controlling compilation and installation are different things. As for the rest, you want to read a very broad definition of script into it. This is going to go very badly for you. Scripts are not the same as their data files or external requirements :) The script is the script. The combined script + datafiles+whatever is clearly a combined work. It's not even, in general, colloquially referred to as a script, it's usually referred to as a package or a distribution or any of a hundred other things. "What exactly would you say that "scripts used to control ... installation" includes? " Literally any files that are scripts that are used in the installation. Data files they use, unless covered otherwise, would not be covered. "And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? " Most lawyers take a pretty strict definition of script. The script part is the script. Again, anything else would not need to be shipped unless otherwise covered by some other part of the requirement. In most cases, it happens to be. For example, it's likely BASE-ADDR.txt is part of the executable's source, or generated by the build system, or whatever else. Now, pragmatically, in order to try to keep everyone happy, some companies will ship all the non-proprietary utilities/data files necessary to run the script (though not necessarily as source), but that is a nicety, not required by GPLv2. Your argument starts to also extend very broadly, what if my script requires a special fuse plugin for my company's magic distributed file system that i store all this stuff on, and becomes worthless without it. Do you believe i have to give you the plugin? The source to the plugin? etc
- jheriko 11y ago
  i'll add this to the very long list of reasons to never even consider using a GPL license...
- asuffield 11y ago
  I would like to state quite firmly that releasing the signing keys is absolutely the wrong solution to this problem, because that destroys the security that code signing was designed to create. The correct solution to this problem is to release a tool for people to change the code signing certificates on their devices to ones which they control, and to arrange for this tool to require a reasonable level of physical access so that it cannot be used remotely. Then device owners can have code signing security on their own terms and be confident that only their own trusted builds can be pushed to their devices via remote updates, which is a super useful feature when you have more than two devices.
drdaeman 11y ago
I highly suspect the word "should" was used not in legal sense, but in ethical one. You're right about GPLv2 — vendors are not legally forced to provide any way to load modified binaries (that's the primary reasoning to license software under GPLv3). Yet, there is a belief that every hardware manufacturer should do so to respect the customers freedom to tinker with the device, especially after the support from vendor is gone.
dragonwriter 11y ago
> If the source is covered by GPLv3, then yeah, if they use code-signing they need to have some way to let you get around it. Only if its a consumer product by the specific rules used in the GPLv3. Business products under the GPLv3 don't require that.
- eridius 11y ago
  Good point, but since businesses don't really care about being able to install modified versions of firmware, I doubt it's controversial.
miah_ 11y ago
s/malicious actors/hardware owners/ See, I bought this WNDR3800 off Ebay, because I wanted to put OpenWRT on it. Its compatible. But I made the mistake of buying a used router that was managed by a ISP. They built their own firmware and purposefully made the firmware updater require specific headers in the firmware package. Now I can't update this device to OpenWRT, without some very specific hacking and compiling my own version of OpenWRT. Who owns this hardware? I bought it. I paid for it. Its in my house. But apparently this ISP is truly the owner and I can't do anything that I wish with this device. The firmware is based on Linux, the ISP of course hasn't released their source. The only way I know about the header bit is because somebody else figured this out years ago and there is a single message on a random web forum detail it. Presumably, the "openness" of the original device running Linux is what allowed them to build their own custom firmware in the first place.
- jabgrabdthrow 11y ago
  I agree you own that hardware. I don't think the ISP is the owner. I just think that the piece of hardware you own is only useful if you have the private keys. That configuration is a physical property of the object you bought. Are you suggesting we should force that manufacturer to tell us some private knowledge he has? Don't try to make a "freedom" argument here. Vote with your Value and buy an unlocked piece of harware.
- eridius 11y ago
  The problem with the argument "I can't do anything that I wish with this device" is it's also the same thing as "Other people can't do whatever they wish with my device". I sympathize with the desire to customize your router firmware, and I think it's important that this ability be available in general (e.g. no laws prohibiting it), and I think it's great that there are devices on the market that allow it, I don't think that any particular vendor should be forced to allow it. If they want to use GPLv3 then they do have to allow it, but it's perfectly legal for vendors using GPLv2 software to put restrictions firmware updates, and I have no objection to that. If you want to customize your firmware, you can simply choose not to buy their product (this of course depends on my earlier statement that it's great that there are devices on the market that do support this). The important point here is that vendors aren't locking down their firmware because they're control freaks that hate when customers install modified firmware, it's also a big security hole. If you can replace your firmware with a modified copy, so can anyone else who manages to gain access to your device. There's other angles too of course, such as vendors who offer unique hardware may want to require their customers to always be using that business's products, as that's how they make money, but when we're talking about generic equipment like routers, the most important reason is security.

by eridius 11y ago

mindslight 11y ago

> The whole point of requiring the firmware to be signed with a specific private key is to prevent third parties from installing their own custom firmware Yes, which is blatantly anti-GPL2. I really wish any Linux copyright holder would step up to the plate and force the argument that since code+signature is the functional unit, adding the signature makes a derivative work and its source must be released in the preferred form for modification. The entire point of the GPL2 is that a developer who creates code and receives a modified version back should be able to modify that instance of code - tivoization is entering into the license in bad faith. Of course going GPL3 would make for a more solid foundation for doing so, but clarifying this subject directly conflicts with the desires of the proprietary sponsors - Google etc.

kinghajj 11y ago
I was under the impression that while it may be against the spirit in which GPL2 was written, it was an oversight and the necessary changes were made to GPL3.
- mindslight 11y ago
  As far as I know, it has never been litigated - there is enough work making manufacturers release anything called "source" as it is. People writing new software just go with the clarified GPL3. Based on Linus's views, the Linux kernel being GPL is a happy accident of history. We should be glad it wasn't BSD so we at least ended up with DD-WRT/AOSP/etc. But we also should keep pushing to preserve the freeedoms that fostered it.
- marcosdumay 11y ago
  The problem is that most people releasing GPLv2 software were not involved at its creation, and are doing it for the bare text contents or completely unrelated reasons. The original goals of the creators are not a very relevant reason. Yes, the GPLv3 fixed that, and there was plenty of time for projects to migrate already. Linux won't migrate, Linus already explicitly stated so.
eridius 11y ago
> Yes, which is blatantly anti-GPL2. No it's not. It's anti-GPLv3. GPLv2 absolutely allows tivoization. Stallman thinks this is bad, but not everybody else agrees (I know Linus Torvalds thinks tivoization is fine in the context of GPLv2, and I believe the FSF agrees). > I really wish any Linux copyright holder […] Your argument here is not a legal one. Any Linux copyright holder that did this would lose horribly. And in particular, Linus Torvalds explicitly stated that he does not support relicensing the Linux kernel under GPLv3 because of this (even if it were possible, which it isn't because of the very large number of copyright holders). Source: https://en.wikipedia.org/wiki/Tivoization#GPLv3 https://en.wikipedia.org/wiki/Tivoization#GPLv3 > The entire point of the GPL2 is that a developer who creates code and receives a modified version back should be able to modify that instance of code And they can! But the GPLv2 does not require that the modified code must be able to be installed back on the original hardware by the person doing the modification. > tivoization is entering into the license in bad faith Not by any legal definition of "bad faith", and even with the informal definition, a lot of people would disagree with you.
- mindslight 11y ago
  > the GPLv2 does not require that the modified code must be able to be installed back on the original hardware by the person doing the modification Does not explicitly. From GPL2: > Accompany it [executable code] with the complete corresponding machine-readable source code ... The source code for a work means the preferred form of the work for making modifications to it So, you're telling me that the preferred form for making modifications to the source code of a router does not include the scripts which install onto the router to test those modifications? > Not by any legal definition of "bad faith" The GPL2 and the FSF are very explicit on what the GPL2 is supposed to engender. Accepting the license and trying to circumvent it on a possible technicality (assertion that a signed blob isn't a derivative work, when the only reason anyone is interested in the source code is to run it) looks pretty bad-faith to me. IANAMOAG (I am not a member of a guild, and you probably aren't either). Even if we were, we could still disagree until it was actually litigated. I see no reason to prematurely capitulate Linux devices being non-Free.
  - 11y ago
superuser2 11y ago
Code-signing is a useful and necessary security measure, so long as it is possible for the owner of the device to sign his own code. You need a good way to distinguish between the end-user and someone who has pwned him.
- mindslight 11y ago
  IMHO a well-documented JTAG, USB, or serial interface on the board to change the trust root would suffice. If you wanted to prevent evil maid attacks, then a time lock would actually be more secure than a fixed trust root with respect to downgrade attacks and leaked keys.
znfi 11y ago
Here is Linus discussing GPLv3 and tivoization etc at DebConf 14 in quite some depth http://www.youtube.com/watch?v=5PmHRSeA2c8&t=47m20s http://www.youtube.com/watch?v=5PmHRSeA2c8&t=47m20s (Basicly he doesn't consider tivoization to be that much of an issue, and doesn't consider it to be something he wanted when he selected the GPLv2)
michaelmior 11y ago
I think it makes sense to require that any automated firmware updates be signed by the device manufacturer and this this key is never released. This is to protect consumers from malicious third parties who may attempt to install malicious firmware. Then there can either be an option to disable this check or a large warning that is produced when you try to install unsigned code. There's really no point in code signing if everyone has access to the private keys.
- AnthonyMouse 11y ago
  > Then there can either be an option to disable this check or a large warning that is produced when you try to install unsigned code. If the device allows unsigned or self-signed code to be installed then there would be no need to release the signing keys because they are not necessary to make modifications. Releasing signing keys should only be required when it doesn't.
  - michaelmior 11y ago
    Exactly my point.
- marssaxman 11y ago
  I think it makes more sense to simply forbid automated firmware updates. Put a physical switch on the box; I'll press it when I want to update the firmware. No crypto signature needed.
  - michaelmior 11y ago
    What about non-technical users who require firmware updates for bug fixes or new features? You can have a physical button, but if the network has been owned in some way, pressing the button could still lead to malicious firmware being installed. I could see this easily coupled with some social engineering. Control the network and then email users saying that an important update is needed.
    - 11y ago
DannyBee 11y ago
The GPL is rarely litigated. What you are talking about is not blatantly anti-gplv2 IAAL (and an open source licensing lawyer at that, for many years). I'm also a contributor to FSF projects :) Even I would tell you the GPLv2 almost certainly does not cover code signing. It's actually very epxlicit about what needs to be there: That's the whole problem with gplv2: " For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." That's it. It very clearly and explicitly says what you must include, and installation keys in not there. It even says 'scripts used to control installation", not "scripts involved in installation" or anything like that.
- deleted 11y ago
  [deleted]
- mindslight 11y ago
  > What you are talking about is not blatantly anti-gplv2 Someone who buys a router running locked down Linux lacks two out of the four essential freedoms, so yes tivoization is blatantly anti-gpl2. I would say this is a popular (edit: non-legal) opinion, especially given the upvotes I have received. But the legal interpretation may diverge from the spirit and purpose of the license, so I would love to hear the opinions of an experienced lawyer... I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. What exactly would you say that "scripts used to control ... installation" includes? A script that says "cp -f a.out /bin/" most certainly qualifies, no? And how about "st-flash write foo.bin 0x8000000" ? And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? Surely you're not arguing that these scripts "perform" the installation rather than "control" it ?
  - DannyBee 11y ago
    "I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. " So, then we have a problem. Courts assume that drafters who write lists mean something by each member of the list. So they are going to read a definition the differs between controls and installs when they see: " plus the scripts used to control compilation and installation of the executable" IE they will read a definition that means controlling compilation and installation are different things. As for the rest, you want to read a very broad definition of script into it. This is going to go very badly for you. Scripts are not the same as their data files or external requirements :) The script is the script. The combined script + datafiles+whatever is clearly a combined work. It's not even, in general, colloquially referred to as a script, it's usually referred to as a package or a distribution or any of a hundred other things. "What exactly would you say that "scripts used to control ... installation" includes? " Literally any files that are scripts that are used in the installation. Data files they use, unless covered otherwise, would not be covered. "And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? " Most lawyers take a pretty strict definition of script. The script part is the script. Again, anything else would not need to be shipped unless otherwise covered by some other part of the requirement. In most cases, it happens to be. For example, it's likely BASE-ADDR.txt is part of the executable's source, or generated by the build system, or whatever else. Now, pragmatically, in order to try to keep everyone happy, some companies will ship all the non-proprietary utilities/data files necessary to run the script (though not necessarily as source), but that is a nicety, not required by GPLv2. Your argument starts to also extend very broadly, what if my script requires a special fuse plugin for my company's magic distributed file system that i store all this stuff on, and becomes worthless without it. Do you believe i have to give you the plugin? The source to the plugin? etc
jheriko 11y ago
i'll add this to the very long list of reasons to never even consider using a GPL license...
asuffield 11y ago
I would like to state quite firmly that releasing the signing keys is absolutely the wrong solution to this problem, because that destroys the security that code signing was designed to create. The correct solution to this problem is to release a tool for people to change the code signing certificates on their devices to ones which they control, and to arrange for this tool to require a reasonable level of physical access so that it cannot be used remotely. Then device owners can have code signing security on their own terms and be confident that only their own trusted builds can be pushed to their devices via remote updates, which is a super useful feature when you have more than two devices.

drdaeman 11y ago

I highly suspect the word "should" was used not in legal sense, but in ethical one. You're right about GPLv2 — vendors are not legally forced to provide any way to load modified binaries (that's the primary reasoning to license software under GPLv3). Yet, there is a belief that every hardware manufacturer should do so to respect the customers freedom to tinker with the device, especially after the support from vendor is gone.

dragonwriter 11y ago

> If the source is covered by GPLv3, then yeah, if they use code-signing they need to have some way to let you get around it. Only if its a consumer product by the specific rules used in the GPLv3. Business products under the GPLv3 don't require that.

eridius 11y ago
Good point, but since businesses don't really care about being able to install modified versions of firmware, I doubt it's controversial.

miah_ 11y ago

s/malicious actors/hardware owners/ See, I bought this WNDR3800 off Ebay, because I wanted to put OpenWRT on it. Its compatible. But I made the mistake of buying a used router that was managed by a ISP. They built their own firmware and purposefully made the firmware updater require specific headers in the firmware package. Now I can't update this device to OpenWRT, without some very specific hacking and compiling my own version of OpenWRT. Who owns this hardware? I bought it. I paid for it. Its in my house. But apparently this ISP is truly the owner and I can't do anything that I wish with this device. The firmware is based on Linux, the ISP of course hasn't released their source. The only way I know about the header bit is because somebody else figured this out years ago and there is a single message on a random web forum detail it. Presumably, the "openness" of the original device running Linux is what allowed them to build their own custom firmware in the first place.

jabgrabdthrow 11y ago
I agree you own that hardware. I don't think the ISP is the owner. I just think that the piece of hardware you own is only useful if you have the private keys. That configuration is a physical property of the object you bought. Are you suggesting we should force that manufacturer to tell us some private knowledge he has? Don't try to make a "freedom" argument here. Vote with your Value and buy an unlocked piece of harware.
eridius 11y ago
The problem with the argument "I can't do anything that I wish with this device" is it's also the same thing as "Other people can't do whatever they wish with my device". I sympathize with the desire to customize your router firmware, and I think it's important that this ability be available in general (e.g. no laws prohibiting it), and I think it's great that there are devices on the market that allow it, I don't think that any particular vendor should be forced to allow it. If they want to use GPLv3 then they do have to allow it, but it's perfectly legal for vendors using GPLv2 software to put restrictions firmware updates, and I have no objection to that. If you want to customize your firmware, you can simply choose not to buy their product (this of course depends on my earlier statement that it's great that there are devices on the market that do support this). The important point here is that vendors aren't locking down their firmware because they're control freaks that hate when customers install modified firmware, it's also a big security hole. If you can replace your firmware with a modified copy, so can anyone else who manages to gain access to your device. There's other angles too of course, such as vendors who offer unique hardware may want to require their customers to always be using that business's products, as that's how they make money, but when we're talking about generic equipment like routers, the most important reason is security.