Developer key philosophy: Difference between revisions
No edit summary |
(→Notes: avoid confusing cryptographic keys with colloquial name for memory device) |
||
| (7 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
{{ |
{{draft}} |
||
This page explains the reasons we have implemented developer keys. For information on what developer keys are, see the page on [[activation and developer keys]] for an overview, or [[developer keys]] for specific information on how to obtain and use that kind of key. |
|||
''For a more complete description of developer keys, see [[Activation and developer keys]].'' |
|||
== Motivation == |
|||
The XO contains hardware and software theft deterrence features, which can get in the way of a prospective hardware or software developer. A 'developer key' allows a developer to bypass these theft deterrence features if needed, so the first step in joining the developer community is requesting a key. |
|||
Well-designed software and hardware, when properly made, should let you do the things you are supposed to do. Another part of good design is ensuring that people who are not supposed to be able to do things (for instance, stealing laptops, or maliciously installing software intended to break an XO on a child's computer) are unable to do them. |
|||
While there are many things a developer can edit without a developer key, a request can take up to two weeks, so it is important to put in a request as soon as possible--that way when a developer key is needed it is available. See [[Activation and developer keys]] for instructions on requesting and installing a developer key. |
|||
Instead of locking down what children can and cannot do with the software on their machines, we have chosen instead to allow them to do ''whatever they want'' within a safe environment - as long as they are running a stable build that has been signed off on by OLPC to have working security (and other vital features), they can do pretty much whatever they want. |
|||
==Using a Developer Key== |
|||
Once it is received, there are two ways to use a developer key: |
|||
# By installing the developer key in /security/develop.sig, where it can be managed with the Security control panel (<trac>6428</trac>). |
|||
# By invoking 'disable-security' from the Open Firmware prompt to skip all key checking (until you invoke 'enable-security' again). This also turns off "pretty boot," allowing you to see all the start up messages when you boot. |
|||
Developers, however, don't always want a "safe environment." It's important for developers to be able to use and test software that might crash, as it's better to find a bug on a developer's machine than on the XOs of 10,000 schoolchildren. A developer key allows a developer to bypass security features on their machine so they can experiment with bleeding-edge software. |
|||
While this choice is left to the developer, the former option is recommended, because it exercises the key-checking and "pretty boot" code. This ensures that developers are regularly testing this code, so that any bugs can be quickly discovered and fixed--instead of making it to the machine of some poor six year old in Peru. |
|||
== What isn't locked down == |
|||
Using the Security control panel also allows developers to easily enable and disable the theft deterrence features. This way, a developer can test code with theft deterrence enabled when necessary. While this is also possible with 'enable-security' from the Open Firmware prompt, this will perform fewer safety checks, making it easier for a developer to inadvertently lock himself out of his machine. |
|||
Even without a developer key, children can still do all these things (and more): |
|||
| ⚫ | |||
* Browse the web freely, without locks or filters (unless their particular deployment, school, teacher, or parent implements them). |
|||
* Download whatever learning materials they want. |
|||
* Install and run whatever software Activities they want on their XO - our security system prevents Activities from interfering with each other and with a child's data, so even if an Activity were to be maliciously designed, it would not break anything else on the laptop. |
|||
* Install and run signed, stable, OLPC-approved operating system and Sugar (UI) builds. |
|||
== What is locked down == |
|||
These are the things you ''cannot'' do without a developer key. |
|||
* Install unstable, unsigned, or experimental OLPC software builds on your XO. |
|||
* Temporarily run, or install, a Fedora, Ubuntu, Gentoo, or Microsoft operating system (nor anybody else's except OLPC's). |
|||
* Type commands to the firmware (e.g. tell it what media to boot from). |
|||
== How to open the lock == |
|||
Every XO user -- this means you, kids! -- has a right to unlock their own machine. This right is guaranteed by the GNU GPLv3 license on much of the software in the machine, and is also part of the [[OLPC on free/open source software|basic philosophy]] of the OLPC organization. Anyone can get a developer key (each machine needs a different key). See [[Activation and developer keys]] for how to do so. Any laptop user who values their rights -- that means you, kids! -- should get a developer key if they don't want to be restricted in how they can use their laptop. |
|||
== So why is there a lock, if anyone can open it? == |
|||
The theory is that if your machine is stolen, it will refuse to run. The thief could get around this refusal if they could install any kind of software on the machine. In theory, a stolen laptop will not be given a developer |
|||
key, if the thief asks for one after it is stolen. It is an option of each country, whether they want their |
|||
laptops to arrive locked, or unlocked. Give 1 Get 1 donors do not get an option; theirs arrive locked, though for inscrutable reasons, not for anti-theft reasons. As of October 2008, no stolen laptop has ever been successfully turned off |
|||
by this mechanism. Every laptop user suffers a loss of freedom, in the hope that one day, at least one thief will be punished, or perhaps deterred. |
|||
== Notes == |
|||
Our current implementation is not ideal. Some things that you currently need a developer key to do (auto-installation of rpms from a USB flash memory drive, for example) are things that we would like to move into the list of features that a child or teacher could do without a developer key. However, until we can come up with a stable, secure way for these features to be implemented on a child's XO, only developers experimenting with new builds and software can do these things. (Ordinary users can install RPM's over the network with "yum install", and can install RPM's from USB memory device using "rpm install". These commands work in the Terminal after turning on root privileges with the button toward the upper right corner.) |
|||
| ⚫ | |||
[[Category:Philosophy]] |
[[Category:Philosophy]] |
||
Latest revision as of 22:33, 5 August 2009
|
NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... |
|
This page explains the reasons we have implemented developer keys. For information on what developer keys are, see the page on activation and developer keys for an overview, or developer keys for specific information on how to obtain and use that kind of key.
Motivation
Well-designed software and hardware, when properly made, should let you do the things you are supposed to do. Another part of good design is ensuring that people who are not supposed to be able to do things (for instance, stealing laptops, or maliciously installing software intended to break an XO on a child's computer) are unable to do them.
Instead of locking down what children can and cannot do with the software on their machines, we have chosen instead to allow them to do whatever they want within a safe environment - as long as they are running a stable build that has been signed off on by OLPC to have working security (and other vital features), they can do pretty much whatever they want.
Developers, however, don't always want a "safe environment." It's important for developers to be able to use and test software that might crash, as it's better to find a bug on a developer's machine than on the XOs of 10,000 schoolchildren. A developer key allows a developer to bypass security features on their machine so they can experiment with bleeding-edge software.
What isn't locked down
Even without a developer key, children can still do all these things (and more):
- Browse the web freely, without locks or filters (unless their particular deployment, school, teacher, or parent implements them).
- Download whatever learning materials they want.
- Install and run whatever software Activities they want on their XO - our security system prevents Activities from interfering with each other and with a child's data, so even if an Activity were to be maliciously designed, it would not break anything else on the laptop.
- Install and run signed, stable, OLPC-approved operating system and Sugar (UI) builds.
What is locked down
These are the things you cannot do without a developer key.
- Install unstable, unsigned, or experimental OLPC software builds on your XO.
- Temporarily run, or install, a Fedora, Ubuntu, Gentoo, or Microsoft operating system (nor anybody else's except OLPC's).
- Type commands to the firmware (e.g. tell it what media to boot from).
How to open the lock
Every XO user -- this means you, kids! -- has a right to unlock their own machine. This right is guaranteed by the GNU GPLv3 license on much of the software in the machine, and is also part of the basic philosophy of the OLPC organization. Anyone can get a developer key (each machine needs a different key). See Activation and developer keys for how to do so. Any laptop user who values their rights -- that means you, kids! -- should get a developer key if they don't want to be restricted in how they can use their laptop.
So why is there a lock, if anyone can open it?
The theory is that if your machine is stolen, it will refuse to run. The thief could get around this refusal if they could install any kind of software on the machine. In theory, a stolen laptop will not be given a developer key, if the thief asks for one after it is stolen. It is an option of each country, whether they want their laptops to arrive locked, or unlocked. Give 1 Get 1 donors do not get an option; theirs arrive locked, though for inscrutable reasons, not for anti-theft reasons. As of October 2008, no stolen laptop has ever been successfully turned off by this mechanism. Every laptop user suffers a loss of freedom, in the hope that one day, at least one thief will be punished, or perhaps deterred.
Notes
Our current implementation is not ideal. Some things that you currently need a developer key to do (auto-installation of rpms from a USB flash memory drive, for example) are things that we would like to move into the list of features that a child or teacher could do without a developer key. However, until we can come up with a stable, secure way for these features to be implemented on a child's XO, only developers experimenting with new builds and software can do these things. (Ordinary users can install RPM's over the network with "yum install", and can install RPM's from USB memory device using "rpm install". These commands work in the Terminal after turning on root privileges with the button toward the upper right corner.)