Weekly Edition
Return to the Security page
| |||||||||||||
The story behind the mysterious CyanogenMod update
A group called Lookout Mobile Security has put out an
alert regarding malware which is targeting custom Android builds.
"The application follows the common pattern of masquerading as a
legitimate application, though a few extra permissions have been added. At
first glance, it appears like other recent Android Trojans that tries to
take control over the mobile phone by rooting the phone (breaking out of
the Android security container), but instead jSMSHider exploits a
vulnerability found in the way most custom ROMs sign their system
images. The issue arises since publicly available private keys in the
Android Open Source Project (AOSP) are often used to sign the custom ROM
builds. In the Android security model, any application signed with the
same platform signer as the system image can request permissions not
available to normal applications, including the ability to install or
uninstall applications without user intervention." This, it seems,
is the vulnerability closed by the May 2011 CyanogenMod security update.
(Seen on The H).
(Log in to post comments)
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 17:04 UTC (Fri) by rahvin (subscriber, #16953) [Link]
Wow, Insecurity through design. Google better hope no one every takes their private keys. In fact I would have to wonder if maybe those system breaches by the Chinese crackers didn't in fact gain access to the keys for this very purpose. I can't believe they deliberately set it up so that if software is signed by the root private key it gets an automatic backdoor into the system. That's a major story right there.
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 20:12 UTC (Fri) by drag (subscriber, #31333) [Link]
How is third party firmwares foolishly using private keys stored in a public repository a design flaw? It's human error.
It's like people using the 'snakeoil' SSL certs provided by fedora installs to protect their financial website logins. You can't design something smart enough to defeat human stupidity.
So the android developers learn to take signing a bit more seriously and everybody moves on. If anything the trojan app developer has done us all a favor.
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 22:47 UTC (Fri) by rahvin (subscriber, #16953) [Link]
Maybe I'm reading it wrong, I'm not blaming CyanogenMod, they did the right thing. The flaw here at least according to how I read it lays with Android's design. Consider for a moment that if the private Google Keys for the commercial version of Android were compromised that the person obtaining the keys would then have access to remotely install any application onto any Andriod phone without user consent and basically turn the phone into a great big spy device.
What if the NSA got a hold of the keys and remotely took over everyones phones for spying purposes? (such as having the microphone active at all times scanning for key words). That the Android system would accept any software signed with the private key signature as equivalent to root access is incredibly scary and looks like a backdoor to me. This was only exposed because the private key for the CyanogenMod versions is publicly available. Please tell me I'm reading this wrong and that all Android devices don't have this great big back door.
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 22:54 UTC (Fri) by Hausvib6 (guest, #70606) [Link]
s/Android/Windows/g
s/Google/Microsoft/g
Yeah, sure, a really big back door. Like how Debian FTP Master has the private keys to Debian's repo?
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 22:58 UTC (Fri) by corbet (editor, #1) [Link] A compromise of the Debian signing key would be bad news for sure. But this is a different situation: it gives an application (which is supposed to be sandboxed) extra privileges to mess with the handset in ways that few users are probably expecting. It does seem like a bit of a misfeature; one wonders why they added it.
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 23:22 UTC (Fri) by elanthis (guest, #6227) [Link]
Because OS applications need more power/flexibility than downloaded apps in order to actually support the low-level frameworks and facilities those downloaded apps need and use, and it's beneficial to let users install, uninstall, and upgrade those system components individually. This is the correct (possibly only) design that doesn't involve locking down the firmware and core UX applications (which is what devices like the older Nintendo handhelds did).
The story behind the mysterious CyanogenMod update Posted Jun 18, 2011 13:15 UTC (Sat) by ballombe (subscriber, #9523) [Link]
No. They could use a different private key to activate that.
The story behind the mysterious CyanogenMod update Posted Jun 19, 2011 1:38 UTC (Sun) by drag (subscriber, #31333) [Link]
>No. They could use a different private key to activate that.
I am thinking there is some confusion going on here.
'They' is 'who'?
If 'They' == 'Google'?
Well I believe that Google just provides a example key along with the repositories, I am guessing with the expectation that system integrators are going to replace it with their own private key.
If 'They' == 'Cyanogenmod et al.'?
Absolutely. They should be using a different private key.
The story behind the mysterious CyanogenMod update Posted Jun 19, 2011 12:05 UTC (Sun) by ballombe (subscriber, #9523) [Link]
I meant that the private key used to sign the ROM and the private key used to grant privileges should not have to be related.
The story behind the mysterious CyanogenMod update Posted Jun 20, 2011 1:59 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
Maybe.
You can fool yourself by creating separate privileges that are interchangeable.
For example, obviously a custom firmware could allow you to disregard runtime restrictions from the default OS, so the firmware privilege is as good as having the native software privilege. But suppose native software is allowed to install new firmware. In this case the native software privilege is also as good as having the firmware privilege.
I don't know if that's actually the case, but it's easy to believe it could be. And if it is, they're interchangeable, providing two separate keys just doubles the attack surface.
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 22:51 UTC (Fri) by Hausvib6 (guest, #70606) [Link]
Err, that's why it's called private key, right? It should be private. Using something public as private sounds really wrong.
Who knows what will happen if my front door key is the same as my neighbours.
The story behind the mysterious CyanogenMod update Posted Jun 17, 2011 23:56 UTC (Fri) by j16sdiz (guest, #57302) [Link]
Publishing private keys.... isn't that what anti-tivolization folks and GPL3 asked for?
The story behind the mysterious CyanogenMod update Posted Jun 18, 2011 1:41 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
The anti-tivoization folks asked that tivoization be prevented. If you decide to lock down your hardware so that only firmware signed with a specific key is acceptable, then yes, you will have to reveal that key.
On the other hand, if the device instead accepts any hardware so long as it is signed with a known key, and provides a trivial but mildly inconvenient way for the person in physical possession of the device to add or change keys to the "known" list, then instantly you don't need to provide your private keys, because no tivoization is threatened by you keeping those keys secret.
publishing private keys / anti-tivoization Posted Jun 18, 2011 8:55 UTC (Sat) by laf0rge (subscriber, #6469) [Link]
> The anti-tivoization folks asked that tivoization be prevented. If you
> decide to lock down your hardware so that only firmware signed with a > specific key is acceptable, then yes, you will have to reveal that key.
This is a common misunderstanding. There is a perfectly legitimate alternative solution: Provide the user with means to install his own public key into the device.
This way, the vendor can keep his private key private, and the user can generate a new public+private key pair + install the public part into the device bootloader or other signature-verifying component.
publishing private keys / anti-tivoization Posted Jun 18, 2011 12:16 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
How is that not what my second paragraph says?
publishing private keys / anti-tivoization Posted Jun 18, 2011 19:44 UTC (Sat) by mingo (subscriber, #31122) [Link] On the other hand, if the device instead accepts any hardware so long as it is signed with a known key, and provides a trivial but mildly inconvenient way for the person in physical possession of the device to add or change keys to the "known" list, then instantly you don't need to provide your private keys, because no tivoization is threatened by you keeping those keys secret. Do you mean a person in physical possession of the device should be able to change keys and install any software on it via a method that is only "mildly inconvenient", such as a thief?
publishing private keys / anti-tivoization Posted Jun 18, 2011 20:11 UTC (Sat) by mrjk (subscriber, #48482) [Link]
Yes, That is exactly the point. Right now the end users are being treated like thieves just as you say. This way would treat end users not like thieves but like real owners of their handsets and take the risk that if stolen, the handset will be like a portable radio or any other old device and will be useful to the thief. I'd take that risk personally.
publishing private keys / anti-tivoization Posted Jun 18, 2011 20:40 UTC (Sat) by mingo (subscriber, #31122) [Link] I think you have misunderstood my comment. There's a real advantage in not having physical access to the machine: a thief won't (easily) get access to it either. Why does the GPLv3 disallow this kind of protection against theft?
I think you are attacking a strawman... Posted Jun 18, 2011 21:21 UTC (Sat) by khim (subscriber, #9252) [Link] Why does the GPLv3 disallow this kind of protection against theft? It does not disallow this. Cr48 scheme (toggle the switch to wipe the device with all it's information and make it ready for OS reinstall) is perfectly compatible with GPLv3. Sure, after such an operation information is lost forever... but that's Ok: thief already have an ability to wipe everything no matter what protection is used. Sledgehammer usually works fine and flametorch will work even better.
I think you are attacking a strawman... Posted Jun 18, 2011 21:34 UTC (Sat) by mingo (subscriber, #31122) [Link] You have missed the rather important fact that you are giving a working device to a thief ... So again, why does the GPLv3 not allow locked hardware as protection against theft? It's an obvious safeguard.
I think you are attacking a strawman... Posted Jun 18, 2011 23:26 UTC (Sat) by nybble41 (subscriber, #55106) [Link]
> So again, why does the GPLv3 not allow locked hardware as protection against theft? It's an obvious safeguard.
The obvious answer is that if you can lock down a device such that a thief cannot load modified software, you can also lock down the same device such that its new legitimate owner cannot load modified software, defeating the purpose of the GPL.
I think you are attacking a strawman... Posted Jun 18, 2011 23:37 UTC (Sat) by bronson (subscriber, #4806) [Link]
I assume Ingo's point is that the GPLv3 prevents the legitimate owner from locking down his own machine.
That seems odd, doesn't it?
I think you are attacking a strawman... Posted Jun 18, 2011 23:50 UTC (Sat) by nybble41 (subscriber, #55106) [Link]
Not really. You can't have it both ways, and the authors of the GPLv3 apparently felt that it was more important that owners be able to modify the software on their own devices than that the devices be capable of preventing subversion by thieves.
I think you are attacking a strawman... Posted Jun 19, 2011 9:24 UTC (Sun) by mingo (subscriber, #31122) [Link] Not really. You can't have it both ways, and the authors of the GPLv3 apparently felt that it was more important that owners be able to modify the software on their own devices than that the devices be capable of preventing subversion by thieves. I.e. the GPLv3 is declaring a tool (restricting hardware in specific ways) as evil summarily, playing the moral police. You've just discovered one particular incarnation of unintended collateral damage that is inevitable when politicians start legislating moral values ... This sums up one of the objections that many Linux kernel developers have against the changes in the GPLv3.
I think you are attacking a strawman... Posted Jun 19, 2011 12:51 UTC (Sun) by DOT (subscriber, #58786) [Link]
Everything is morals. The anti-tivoization principle is morals. The quid pro quo principle is morals. Even the "use this for any purpose" is morals. Sure, quid pro quo also gives you a practical advantage (you get code), but the same goes for anti-tivoization (you get to modify), and obviously also for the usage for any purpose.
Legislation is always about morals. The objections can't be that the license legislates morals. The objections can only be that they are 'the wrong morals'.
I think you are attacking a strawman... Posted Jun 19, 2011 13:08 UTC (Sun) by mingo (subscriber, #31122) [Link] Quid pro quo isn't morals, it's the fundamental force of evolution: it's an optimum survival strategy that comes straight out of game theory (math). But even if we assumed it was morals (which it isn't), there's a world of a difference between a thousands of years old concept shared by every single developed culture that ever lived on the planet and a petty 20th century vendetta against 'evil Tivo' and the resulting micro-management and paranoid complication of a previously pretty good and simple license, mainly based on the morals of RMS and ignoring the morals of the developers who wrote the other 95% of code ... It's also a double standard: RMS talks against tyranny yet the way he handles GPL iterations is arrogance of someone in power at its finest - democracy and listening to others is clearly not a moral standard he values very high. Anyway, the (non-)uptake of the GPLv3 by major OSS projects is plenty of proof that there's widespread developer dislike against it - and I just shared my view that the stupid anti-Tivo clauses are one reason for that.
I think you are attacking a strawman... Posted Jun 19, 2011 16:04 UTC (Sun) by DOT (subscriber, #58786) [Link]
Game theory scheming is pretty much how I would describe all strategies employed by the GPL, including anti-tivoization.
It's not a vendetta against Tivo so much as a strategy to discourage the urge of companies to lock device owners out of their own systems. Freedom to tinker, and all that.
>Anyway, the (non-)uptake of the GPLv3 by major OSS projects is plenty of proof that there's widespread developer dislike against it - and I just shared my view that the stupid anti-Tivo clauses are one reason for that.
Desktop Linux sucks 99%.
I think you are attacking a strawman... Posted Jun 19, 2011 18:42 UTC (Sun) by mingo (subscriber, #31122) [Link] Game theory scheming is pretty much how I would describe all strategies employed by the GPL, including anti-tivoization. "Scheming" indeed describes the GPLv3 pretty well. But you need to realize that you crossed a line of fairness: "freedom to tinker" is a random wish that developers have, which extends to the hardware (something which typically has no derivative relationship with the software we run on it), which has nothing to do with fair, reciprocal code sharing. We don't have the moral basis to try to control hardware that was independently created. Yes, copyright law is viral enough to enable such abuse, but that does not make it right. Does the GPLv4 want to add newly thought out random wishes that developers have? Here's a selection of possibilities: - Free hardware for the FSF? For the good of free software, of course. - Corporate executives of companies utilizing GPLv4 software are required to put a song on Youtube, singing about the freedom to tinker. Only this can ensure that they truly believe in free software and in the freedom to tinker. - Free tea for RMS in the corporate cafetteria. (ok, scratch that one, it's too obvious, although this too would obviously for the good of free software.) - Will the GPLv4 legislate freedom of choice, or is it going to be pro life? I mean, without proper morals there isn't going to be proper free software either. Where does the power grab stop and how much crap can you add to the GPL before it becomes a license no-one will consider a fair, reciprocal license anymore? Many kernel developers feel that this line has been crossed with the GPLv3 already and are sticking to the GPLv2. You have moved politics and power play into the GPLv3 without even realizing it, and you call it 'morals' and that simply sucks, and that is why we are staying with the GPLv2 in the kernel: it's a simple reciprocal license that encourages the sharing of working code (genes) - it does not try to abuse its position, it does not try to legislate its dominance ...
Desktop Linux sucks 99%. It does. It's also pretty telling how you skipped over my remark that the creation of the GPLv3 was an example of arrogant abuse of power.
I think you are attacking a strawman... Posted Jun 19, 2011 22:48 UTC (Sun) by DOT (subscriber, #58786) [Link]
> It's also pretty telling how you skipped over my remark that the creation of the GPLv3 was an example of arrogant abuse of power.
[It's too late to do a full reply.] I try to ignore unsubstantiated flames. For what it's worth: the GPL is maintained by an entity and we put our trust in that entity. Version 3 had a long feedback period and if I recall correctly, the details about the anti-tivoization clause were changed as a result. It's most definitely not a democracy, but there is of course the possibility of moving to another license. Power can't be abused if it's not acquired.
I think you are attacking a strawman... Posted Jun 20, 2011 1:51 UTC (Mon) by Trelane (subscriber, #56877) [Link]
> We don't have the moral basis to try to control hardware that was independently created.
Wow.
Just. Wow.
I could not disagree with you more on this point.
The creator is irrelevant; it's the *owner* that matters. Or is it OK if Stanley controls what you may and may not do with your shovel?
I think you are attacking a strawman... Posted Jun 20, 2011 2:08 UTC (Mon) by Trelane (subscriber, #56877) [Link]
The commingling of ownership and control are evident in the definitions of "own" and "possess":
http://www.merriam-webster.com/dictionary/own http://www.merriam-webster.com/dictionary/possess
Specifically,
> a : to seize and take control of : take into one's possession
I think you are attacking a strawman... Posted Jun 20, 2011 3:34 UTC (Mon) by jake (editor, #205) [Link]
> But you need to realize that you crossed a line of fairness:
> "freedom to tinker" is a random wish that developers have, which > extends to the hardware (something which typically has no derivative > relationship with the software we run on it), which has nothing to > do with fair, reciprocal code sharing.
I don't think it's unreasonable for someone to license their code such that, if it is used in a piece of hardware, they require that anyone receiving that hardware have the ability to change that code. I can certainly understand folks believing that if their code is used in a device, they should (and others should) be able to change it if they so desire. That seems like a perfectly reasonable position for someone who donates code to take. That, of course, doesn't mean that everyone should be required to require that on their code, that's why we have different licenses.
The problem, it seems to me, is that it was added into the GPL, which changes that license in ways that some who were quite happy with v2 do not agree with. But, at some level, that's a different question. You (and plenty of others) may not be happy with what's in GPLv3 and how it came about (though, in my mind, it's very much in keeping with what the FSF has always been aiming for), but it's a different license. Perhaps some projects got "tricked" into the new language by licensing their code as GPLv2+, though I think that's an overblown concern, personally, but it doesn't affect projects like the kernel which were plain GPLv2.
I really don't think it crosses any line for the developers of some codebase to decide they want to ensure that they and others can change any instantiation of it in hardware. That may not be your choice (or other kernel developers) and that's just fine. But to declare that the only "fair" choice is GPLv2 is going a bit too far imo.
jake
I think you are attacking a strawman... Posted Jun 20, 2011 8:37 UTC (Mon) by mingo (subscriber, #31122) [Link] I don't think it's unreasonable for someone to license their code such that, if it is used in a piece of hardware, they require that anyone receiving that hardware have the ability to change that code. Of course that request is unreasonable in that simple form you stated, and the many hand-carved-out exceptions in the GPLv3 prove that: it's very unreasonable to request the hardware to be modified if it's a single-purpose piece of hardware that was not designed to be modified. (there are other cases as well) Also note how the GPLv3 actually achieves that: by restricting use in essence. (and yes, legally it operates over the concept of 'distribution' applied to a collection of works [extending the scope of the GPL to the other works as well] which it morphs into 'conveyance' but copyright law is extremely viral so it can affect even completely separately created works like hardware if they happen to be even close to each other. Ask the RIAA/MPAA whether they like it that way.) So copyright law can very much be used for immoral purposes and it can be used to land-grab and control some other person's work - to steal in essence. So if the kernel was GPLv3 then people could not take an already built kernel image, sign it onto hardware and distribute the result (keeping the key) without giving their key with it. That's the very definition of restriction of usage and no amount of lawyering about 'conveying' changes that fundamental fact. And yes, who wouldn't agree that keeping evil telcos from locking down phones while preserving their own right to update the hardware for their enrichment is a "good" thing? Who wouldn't agree that keeping evil terrorists from imprisoning people while they preserve their own right to free them is a "good" thing? Who wouldn't agree that keeping evil parents from locking down kid's doors while preserving their own right to unlock them is "good" thing? (oops, life isn't so simple, is it? Does the GPLv3 have exceptions for parental control? What other fine details of life has it considered and did it miss any?) My moral argument is very simple: i don't want to get into the business of restricting others from doing 'obviously bad' things with works i did not create, just because my work is used on that device as well, even if copyright law has the legal loopholes to give me control over the distribution of those works. For example if i could i'd forbid anyone modifying the kernel in an ugly way. And heck if all kernel authors agreed we would have the legal right to do that: we could establish a Kernel Code Cleanliness Foundation which has to pre-approve modifications to the kernel and which would also create a tool that checks code for cleanliness - code could be pre-shipped for a time limit that passes this validation. This really matters to the 'right to tweak' a lot more than device lock-down: we can re-flash devices just fine (or build our own ones) but you cannot tweak impossible to read code! In practice this would help free software and hackability a lot more than any anti-Tivo clauses .. If i could i'd also probably forbid anyone from modifying the kernel to kill other people. (This obviously connects into the issue of 'right to tweak', you obviously cannot tweak if you are dead, right?) The list goes on and on. Everyone has their own set of values of what use 'should' be performed with their works and what not and creative lawyering can be used to tie that into a license. RMS does not like hardware that can not be modified by the owner, so he wanted the GPLv3 to forbid that kind of use and copyright law is full of loopholes to allow that. I just don't think that the kernel license should get into the business of deciding between 'good' and 'evil' uses and then forcing that opinion on others, because even if you ignore that the way it was implemented is immoral and is a form of theft, even if you ignore that the GPLv3 is clearly dissimilar in spirit to the GPLv2 (the GPLv3 broke the promise outlined in the GPLv2 and is thus not a valid 'new version' of the GPL in my opinion), it's also bad from a pragmatic angle: human history has shown us that trying to do that brings more evil than good in the long run. Lets keep the eye on the ball and do what we do well: create good code and make sure that the code we wrote and published stays open. That is what matters. Trying to do more will only increase the effective price of the GPL and will make us less of a fair quid pro quo to the rest of society (and more of a legal risk to companies, if you just check the size increase of GPLv3 versus GPLv2 ...) - who will be happy to flock to the iSpace walled gardens no problem.
I don't understand any of this! Posted Jun 20, 2011 10:57 UTC (Mon) by ketilmalde (guest, #18719) [Link]
(First, Jake is talking about the right to modify your code, not the hardware. Does that make a difference to your argument? You seem to be focused on asserting rights over other's code, but I thought the GPL family and tivoization was about rights to run modified versions of the GPL - i.e. "your" - code. No?)
I don't understand how GPL3 prevents me from locking down a device I own. How does it stop me? Clearly not through copyright law - I didn't copy (nor "publicly perform") anything. Similarly, I don't see how I'm liable in any way to thieves, I'm hardly "distributing" anything to them - if anything, they are distributing my stuff to themselves.
And, AFAIU, the kernel developers are already policing the mainline kernel for cleanliness. The problems with 'right to tweak' reduced by ugly code must thus be due to forks, and your "cleanliness" license would of course prevent this. Interestingly, being limited to mainline would severely limit the utility of tivoization. :-)
One final point: I think one unavoidable reason Linux isn't moving to GPL3 is practical - it's difficult to even identify all contributors, and clearly impossible to get them all to agree on a such a licensing change. So any discussion about it is entirely hypothetical.
(I haven't read the GPL in detail, so I'm likely wrong on some accounts. Please educate me!)
I don't understand any of this! Posted Jun 20, 2011 11:25 UTC (Mon) by Trelane (subscriber, #56877) [Link]
> I don't understand how GPL3 prevents me from locking down a device I own. How does it stop me?
mingo seems incapable of envisioning a security system that doesn't lock the hardware from the user as well as any eventual others. So in mingo's world, if you lock it away from others, you must necessarily lock it away from the owner as well.
> Clearly not through copyright law - I didn't copy (nor "publicly perform") anything.
That doesn't matter for copyright in general (you don't own the software; you license it under terms set forth by the supplier).
The GPL is non-use, no matter mingo's contortions and distortions. You can copy, modify, and use it however you see fit. The *only* time the license restricts (aside from agreeing to a lack of warranty) is when you "convey" the software, i.e. give it to someone else. See the GPL FAQ items I posted elsewhere in this article.
> Similarly, I don't see how I'm liable in any way to thieves, I'm hardly "distributing" anything to them - if anything, they are distributing my stuff to themselves.
You're not, according to the GPL FAQ (http://www.gnu.org/licenses/gpl-faq.html#StolenCopy)
> The problems with 'right to tweak' reduced by ugly code must thus be due to forks, and your "cleanliness" license would of course prevent this. Interestingly, being limited to mainline would severely limit the utility of tivoization. :-)
That's a mingo red-herring.
And, no, restricting to mainline wouldn't prevent tivoization. The checks are done in hardware (e.g. with a TPM and trusted boot chain verifying the kernel binary's signature).
> I haven't read the GPL in detail, so I'm likely wrong on some accounts. Please educate me!
The FAQ and license itself are very good reads. :) At least browse through the FAQ; some things may surprise you.
I don't understand any of this! Posted Jun 20, 2011 11:48 UTC (Mon) by mingo (subscriber, #31122) [Link] First, Jake is talking about the right to modify your code, not the hardware. Does that make a difference to your argument? You need to check how the GPLv3 operates in such cases: it restricts hardware designs by applying to the whole 'collection of works' even if just one piece of the works is a GPLv3 covered work ... Even on locked down hardware the 'right to modify your code' exists and is met: the source code has to be distributed, it's either in an accompanying CD or DVD or you can download that code and you can read and modify and run that code. Can you download, modify and run it on that piece of hardware? Often you cannot: you cannot plug a CD or DVD into it (it's way too small for it), it might not have any network access or it might not have enough RAM in it to do any reasonable development on it - or you might want to use a piece of hardware that can only be loaded with software that someone else (not you) trusts. What the GPLv3 does is to extend the license to the hardware and restrict certain forms/uses of the hardware, in its petty vendetta against 'Tivo'. As such it violates the principle of the GPL as outlined in the GPLv2. It might be a "pragmatic" violation but nevertheless many kernel developers feel uneasy about it. (Also, the parent poster is blatantly misrepresenting what i wrote.)
I don't understand any of this! Posted Jun 20, 2011 18:11 UTC (Mon) by raven667 (subscriber, #5198) [Link]
But what purpose would it serve to be able to download and modify source code if you were legally prevented from running it and anyone you distributed your modifications to would also be legally barred from running the code?
I think you are attacking a strawman... Posted Jun 20, 2011 13:13 UTC (Mon) by jake (editor, #205) [Link]
> Of course that request is unreasonable in that simple form you
> stated, and the many hand-carved-out exceptions in the GPLv3 > prove that: it's very unreasonable to request the hardware to > be modified if it's a single-purpose piece of hardware that > was not designed to be modified. (there are other cases as well)
But, no one is forcing the hardware designer to use any GPLv3 code. That's the tradeoff that is being offered by projects that license their code that way, and if the hardware designer doesn't like it, they can use some other piece of code that's licensed differently or write their own and license it however they want.
> So copyright law can very much be used for immoral purposes and
Eh? This seems beyond the pale to me ... copyright is the way that the creator restricts the use of their creation. No one is forcing anyone to use the creation in question, so how does it "land-grab and control"?
> Lets keep the eye on the ball and do what we do well: create
Umm, that's what matters *to you* ... other things matter to other people. Trying to make a hard and fast rule about what other folks can do with their code is not going to be very helpful. In fact, the GPLv3 advocates who keep arguing that you should put your code under that license seems to be one of the things that irks you most, don't fall into the same trap.
jake
I think you are attacking a strawman... Posted Jun 20, 2011 18:12 UTC (Mon) by raven667 (subscriber, #5198) [Link]
"And yes, who wouldn't agree that keeping evil telcos from locking down phones while preserving their own right to update the hardware for their enrichment is a "good" thing?"
Customers. Customer complaints are driving some Android phone manufacturers to no longer lock their bootloaders...
I think you are attacking a strawman... Posted Jun 27, 2011 14:41 UTC (Mon) by nye (guest, #51576) [Link]
"So if the kernel was GPLv3 then people could not take an already built kernel image, sign it onto hardware and distribute the result (keeping the key) without giving their key with it. That's the very definition of restriction of usage and no amount of lawyering about 'conveying' changes that fundamental fact."
And if the kernel was GPLv2 then people could not take an already written kernel source tree, compile it for their hardware and distribute the result (keeping the source) without giving their source with it. That's the very definition of restriction of usage and no amount of lawyering about 'conveying' changes that fundamental fact.
I think you are attacking a strawman... Posted Jun 27, 2011 14:49 UTC (Mon) by nye (guest, #51576) [Link]
"the GPLv3 is clearly dissimilar in spirit to the GPLv2 (the GPLv3 broke the promise outlined in the GPLv2 and is thus not a valid 'new version' of the GPL in my opinion)"
You haven't provided any sensible description of why you think the spirit of the two is different. The idea of the GPL came about when RMS wanted to improve and replace his printer driver. Nowadays since everything is filled with signed firmware the only way to achieve that goal is to find a way to prevent Tivoisation, which was invented specifically to exercise that loophole in v2.
If *your* goal with the GPL is something other than 'I want to be able to improve the things I use' then that's all very well, but you can't claim that the spirit has been changed when that's clearly still the goal of v3, and every one of your arguments why GPLv3 is evil applies just as well to v2.
It's even older concept Posted Jun 19, 2011 17:37 UTC (Sun) by khim (subscriber, #9252) [Link] But even if we assumed it was morals (which it isn't), there's a world of a difference between a thousands of years old concept shared by every single developed culture that ever lived on the planet "I own something therefore I can alter something" is pretty old concept. It predates "the developed culture". In fact the developed culture is only possible because if this principle. In the medieval world of guilds (which restricted "tinker rights") changes were very slow and gradual. Only when they were abolished "developed culture" got a chance. Petty 20th century vendetta against 'evil Tivo' and the resulting micro-management and paranoid complication of a previously pretty good and simple license. TiVo and Co are revival of guilds and if they are allowed to persist we'll see the same stagnation so I see nothing "petty" in this vendetta. And GPL never was "simple" - or else all these "GPL FAQ" will not be needed. mainly based on the morals of RMS and ignoring the morals of the developers who wrote the other 95% of code Again: GPL was always about morals of RMS. It's adoption was about morals of others. And it's ok with way more then 95% of developers as facts show. It's also a double standard: RMS talks against tyranny yet the way he handles GPL iterations is arrogance of someone in power at its finest - democracy and listening to others is clearly not a moral standard he values very high. Wow. Talk about bitter. On the contrary, his handling of GPL shows his dedication to the democracy. The developer decide if s/he wants to adopt newer version of GPL or not. Compare with MPL (The Source Code version of Covered Code may be distributed only under the terms of this License or a future version of this License released under Section 6.1) or CC (You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License.) The fact is: GPL is rare copyleft license which gives the developer the right to stick with older version - if this is not a democracy then I don't know what is. You may complain that newer versions are developed and approved by FSF without wide vote, but then other licenses without exception are developed that way too so it's strange complaint. Anyway, the (non-)uptake of the GPLv3 by major OSS projects is plenty of proof that there's widespread developer dislike against it - and I just shared my view that the stupid anti-Tivo clauses are one reason for that. Hardly. As I've already showed developers of new projects actually prefer GPLv3. And the fact that old projects are not switching to it just means they don't feel the effort is worth it. Hardly a "widespread dislike"...
I think you are attacking a strawman... Posted Jun 18, 2011 23:56 UTC (Sat) by jrn (subscriber, #64214) [Link]
> I assume Ingo's point is that the GPLv3 prevents the legitimate owner from locking down his own machine.
But it doesn't, does it? GPLv3 is a license for copying, distribution, and modification, not use.
The manufacturer can provide a method to "imprint" on a single public key and lock down the machine and then distribute the machine without imprinting it. Then the owner installs a public key; the GPL doesn't say anything about that, since it's normal use of the software. Afterwards, if the owner wants to distribute the machine, she would supply the private key along with it to comply with the terms of the GPLv3.
I think you are attacking a strawman... Posted Jun 19, 2011 18:28 UTC (Sun) by JanC_ (guest, #34940) [Link]
> Afterwards, if the owner wants to distribute the machine,
> she would supply the private key along with it to comply > with the terms of the GPLv3.
Or it could be possible to unlock the phone by using the private key, after which distribution would be fine too.
I think you are attacking a strawman... Posted Jun 20, 2011 1:58 UTC (Mon) by Trelane (subscriber, #56877) [Link]
> GPLv3 is a license for copying, distribution, and modification, not use.
Almost correct.
GPLv3 is a license about distribution. Full stop. Copying isn't controlled; you can make as many copies as you want. Where the license kicks in is when you distribute it to someone else. Modification isn't controlled; you can modify the software to your heart's content. Where the license kicks in is when you distribute it to someone else.
The key word is "conveying;" there are several forms of distribution that are not conveying. Copying is mentioned as one of them:
I think you are attacking a strawman... Posted Jun 19, 2011 0:05 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
The legitimate owner can lock down his own machine.
Selling locked down devices to people is different from locking down your own device.
I think you are attacking a strawman... Posted Jun 25, 2011 14:32 UTC (Sat) by dmag (subscriber, #17775) [Link]
> the GPLv3 prevents the legitimate owner from locking down his own machine.
It does no such thing. You are free to modify/lock the phone in any way you want, as long as you don't distribute it.
The GPL only applies to distribution. If a thief steals your phone, they cannot demand the hardware keys under the GPLv3, nor can they demand the source code under the GPLv3.
And if you want to modify the hardware to brick itself, you could. But don't blame the GPL because the manufacturers didn't build that for you. (GPL aside, an easily-brickable device is nice for the spy market, but would fare worse in the general market.)
I think you are attacking a strawman... Posted Jun 18, 2011 23:46 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
"It's an obvious safeguard."
No, it isn't. Theft is a subtle thing, some poor little electronic device doesn't know it's been stolen. At best you've found a way for manufacturers to get a "transfer charge" out of people exercising their first sale rights.
I think you are attacking a strawman... Posted Jun 20, 2011 6:26 UTC (Mon) by rusty (✭ supporter ✭, #26) [Link]
> So again, why does the GPLv3 not allow locked hardware as protection against theft? It's an obvious safeguard.
It does. Perhaps you should actually read it?
Rusty.
The story behind the mysterious CyanogenMod update Posted Jun 19, 2011 10:19 UTC (Sun) by russell (subscriber, #10458) [Link]
In what way is it private... Did the user generate the key when it was installed into the ROM??? No, that's the fault. It's someone else's private key. This is generally known by the other name, "backdoor".
|
|||||||||||||