Developer key philosophy: Difference between revisions
(..) |
mNo edit summary |
||
| 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. |
|||
== 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. |
|||
: Please note: our current implementation is not ideal, and developer keys are being used to limit a user's exposure to security risks such as auto-installation of rpm's and other software from USB keys, installation of anything but the most stable quarterly OLPC builds, and the like. This reduces the overall effectiveness of the system, since almost everyone who wants to play around with their machine is encouraged to get a developer key. --[[User:Sj|Sj]] [[User talk:Sj|<font style="color:#f70; font-size:70%">talk</font>]] 00:11, 29 September 2008 (UTC) |
|||
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 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 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, experimental builds on your XO. |
|||
* Work with the firmware. |
|||
== 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 key, 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. |
|||
[[Category:Developer]] |
[[Category:Developer]] |
||
Revision as of 21:04, 6 October 2008
|
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 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 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, experimental builds on your XO.
- Work with the firmware.
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 key, 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.