Benjamin M. Schwartz
2007-12-21 05:16:56 UTC
This is a brain dump of my thoughts on how to encourage user-created activities
without compromising security.
My Proposal:
I am proposing a design for packaging and upgrading Activities. Something very
much like this design has been discussed by others before; I am merely filling
in details.
A. An Activity Package should include:
1. The Activity's contents.
2. A list of Obsoletion Tokens.
3. A list of public keys and names of the Activity's Authors
4. A signature by each Author, using her public key, of 1 + 2 + 3.
5. A hash of 1 + 2 + 3 + 4, which is called the package-hash.
An Activity Package is valid iff the list of Authors in A3 is the same as in A4,
and all hashes and signatures are valid.
B. An Obsoletion Token should be:
1. A package-hash of an obsolete activity.
2. A package-hash of an activity that replaces it.
3. The list of all public keys and names of the Authors of the new version.
4. The name and public key of the Author who asserts that 2 obsoletes 1. This
Author must be an Author of 1.
5. A signature of 1+2+3 by the Author in 4.
When sharing an activity, the announcement sent over the network should include
the package-hash.
When joining an activity, the joiner should compare the advertised package-hash
to all installed packages. If it is already installed, then the installed copy
should be used to join the shared instance. If no Activity with that
package-hash is installed, then the joiner should request a copy of the Activity
Package over the network, verify the downloaded Package's package-hash and
signatures, and use the downloaded copy to join the shared instance.
After downloading the Activity Package and verifying that it is valid, the
joiner should look at the list of Obsoletion Tokens. An Obsoletion Token is
only valid if it is signed by an Author (B4) who is one of the Authors of the
obsoleted version (A3). Each Obsoletion Token lists the Authors of the new
version as well, so that Obsoletion Tokens can safely be chained, even if the
middle version has not been seen. Obsoletion is transitive, so if there is any
chain of Obsoletion Tokens connecting the new Package to an installed Package,
then the installed Package should be replaced by the new Package.
If the newly downloaded copy is obsoleted by an installed package, then it
should be "replaced" by the installed package at the end of the shared session.
Rationale:
By the time I learned of this issue, there seemed to be a consensus: Activities
should be upgraded transparently, automatically, over the mesh, whenever the
person sharing an activity has a new version (and maybe more frequently). In
this way, upgrades will spread virally through the mesh, allowing for fast
bug-fixes even without good internet access. I am in favor of this design.
Automatic upgrades create an obvious risk: someone could create a "hacked"
version of an Activity, number it as a new version, and allow it to spread
through the mesh. This hack might exploit a security bug in Sugar, or merely
disable important functionality. Either way, it is unacceptable to allow users
to mess with the software on others' laptops. Therefore, upgrades must be
signed, to ensure that only the original author can create a new version of a
program.
We want to encourage collaboration on Activity development. Therefore, there
will be multiple authors. Since some Authors may lose interest, any of the
Authors should have the power to declare an upgrade, and upgraded version should
be able to add new Authors as well. This is very convenient. For example, for
the base activities, OLPC should be listed as one author, and the current
programmers should be listed as well. That way, OLPC can maintain upgrade
continuity if current devs disappear.
Obsoletion Token chains are required because, over time, the group of Authors
can change. If a user has not upgraded in a few years, they may find that the
new Activity Package has no Authors in common with the one that they have
installed. However, the new version may still obsolete the installed version.
The Obsoletion Token chains allow the user's OS to verify this.
Issues:
1. Replacement.
It is not clear what replacement should mean. If old datastore objects continue
to be opened with the old version of the package, then upgrades have almost no
significance, and old version can never be removed. On the other hand, if old
versions are removed, then there is a risk of incompatibility, rendering old
datastore objects unreadable.
I feel that the best solution is to demand that if Package Y obsoletes Package
X, then Package Y must be able to open any datastore entries that can be opened
by Package X. This demand is a matter of specification compliance, not enforced
by the OS. With this demand in place, obsolete Packages can be removed immediately.
The above spec does not require new versions to maintain network compatibility
with obsolete versions. I see network backwards-compatibility as much more
difficult than read-only file backwards-compatibility.
2. Authorship
This spec takes the view that all Authors have the ability to declare a new
version, independently. This means that any of the Authors of a version may
create a hostile "fork" of the project that obsoletes that version. I see no
sensible way to avoid this possibility. However, it is not terrible. If the
remaining Authors continue development, their subsequent releases will also be
listed as obsoleting previous versions. If a user has installed the "fork"
version first, then the release by the remaining Authors will not obsolete any
installed Activity, but it will still install cleanly, as a new Activity.
- --Ben
without compromising security.
My Proposal:
I am proposing a design for packaging and upgrading Activities. Something very
much like this design has been discussed by others before; I am merely filling
in details.
A. An Activity Package should include:
1. The Activity's contents.
2. A list of Obsoletion Tokens.
3. A list of public keys and names of the Activity's Authors
4. A signature by each Author, using her public key, of 1 + 2 + 3.
5. A hash of 1 + 2 + 3 + 4, which is called the package-hash.
An Activity Package is valid iff the list of Authors in A3 is the same as in A4,
and all hashes and signatures are valid.
B. An Obsoletion Token should be:
1. A package-hash of an obsolete activity.
2. A package-hash of an activity that replaces it.
3. The list of all public keys and names of the Authors of the new version.
4. The name and public key of the Author who asserts that 2 obsoletes 1. This
Author must be an Author of 1.
5. A signature of 1+2+3 by the Author in 4.
When sharing an activity, the announcement sent over the network should include
the package-hash.
When joining an activity, the joiner should compare the advertised package-hash
to all installed packages. If it is already installed, then the installed copy
should be used to join the shared instance. If no Activity with that
package-hash is installed, then the joiner should request a copy of the Activity
Package over the network, verify the downloaded Package's package-hash and
signatures, and use the downloaded copy to join the shared instance.
After downloading the Activity Package and verifying that it is valid, the
joiner should look at the list of Obsoletion Tokens. An Obsoletion Token is
only valid if it is signed by an Author (B4) who is one of the Authors of the
obsoleted version (A3). Each Obsoletion Token lists the Authors of the new
version as well, so that Obsoletion Tokens can safely be chained, even if the
middle version has not been seen. Obsoletion is transitive, so if there is any
chain of Obsoletion Tokens connecting the new Package to an installed Package,
then the installed Package should be replaced by the new Package.
If the newly downloaded copy is obsoleted by an installed package, then it
should be "replaced" by the installed package at the end of the shared session.
Rationale:
By the time I learned of this issue, there seemed to be a consensus: Activities
should be upgraded transparently, automatically, over the mesh, whenever the
person sharing an activity has a new version (and maybe more frequently). In
this way, upgrades will spread virally through the mesh, allowing for fast
bug-fixes even without good internet access. I am in favor of this design.
Automatic upgrades create an obvious risk: someone could create a "hacked"
version of an Activity, number it as a new version, and allow it to spread
through the mesh. This hack might exploit a security bug in Sugar, or merely
disable important functionality. Either way, it is unacceptable to allow users
to mess with the software on others' laptops. Therefore, upgrades must be
signed, to ensure that only the original author can create a new version of a
program.
We want to encourage collaboration on Activity development. Therefore, there
will be multiple authors. Since some Authors may lose interest, any of the
Authors should have the power to declare an upgrade, and upgraded version should
be able to add new Authors as well. This is very convenient. For example, for
the base activities, OLPC should be listed as one author, and the current
programmers should be listed as well. That way, OLPC can maintain upgrade
continuity if current devs disappear.
Obsoletion Token chains are required because, over time, the group of Authors
can change. If a user has not upgraded in a few years, they may find that the
new Activity Package has no Authors in common with the one that they have
installed. However, the new version may still obsolete the installed version.
The Obsoletion Token chains allow the user's OS to verify this.
Issues:
1. Replacement.
It is not clear what replacement should mean. If old datastore objects continue
to be opened with the old version of the package, then upgrades have almost no
significance, and old version can never be removed. On the other hand, if old
versions are removed, then there is a risk of incompatibility, rendering old
datastore objects unreadable.
I feel that the best solution is to demand that if Package Y obsoletes Package
X, then Package Y must be able to open any datastore entries that can be opened
by Package X. This demand is a matter of specification compliance, not enforced
by the OS. With this demand in place, obsolete Packages can be removed immediately.
The above spec does not require new versions to maintain network compatibility
with obsolete versions. I see network backwards-compatibility as much more
difficult than read-only file backwards-compatibility.
2. Authorship
This spec takes the view that all Authors have the ability to declare a new
version, independently. This means that any of the Authors of a version may
create a hostile "fork" of the project that obsoletes that version. I see no
sensible way to avoid this possibility. However, it is not terrible. If the
remaining Authors continue development, their subsequent releases will also be
listed as obsoleting previous versions. If a user has installed the "fork"
version first, then the release by the remaining Authors will not obsolete any
installed Activity, but it will still install cleanly, as a new Activity.
- --Ben