User:Mstone/Rainflow: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 1: Line 1:
Carrying on the tradition of naming [[Rainbow|software]] via puns, I'll lay down some thoughts here about software for, among other things, answering the question:
Carrying on the tradition of naming [[Rainbow|software]] via puns, I'll lay down some thoughts on how to answer the question:


: ''When should we run program X deisolated?''
: ''When should our software automatically do risky thing X?''


== Background ==
== Background ==


People have been concerned with this question (and with variants and related questions) for some time:
<trac>5657</trac> asked for a way to automatically update [[Terminal]] that is not subject to spoofing.

One natural approach this is activity signing. However, as experience with X.509 has shown, the devil is truly in the details.

To date, we have seen several attempts to discover appropriate details:


: <trac>5657</trac>, on spoofing-resistant update algorithms for de-isolated activities
: [http://lists.laptop.org/pipermail/security/2008-October/000496.html questions on activity signing and update thread]
: [http://lists.laptop.org/pipermail/security/2008-October/000496.html questions on activity signing and update thread]
: [[User:Mstone/Commentaries/Bundles_1|activity semantics conversation]]
: [[User:Mstone/Commentaries/Bundles_1|activity semantics conversation]]
Line 17: Line 14:
: [http://lists.laptop.org/pipermail/devel/2008-March/012131.html horizontal distribution thread]
: [http://lists.laptop.org/pipermail/devel/2008-March/012131.html horizontal distribution thread]
: [[Bundles and updates|homunq's ideas on bundles and updates]]
: [[Bundles and updates|homunq's ideas on bundles and updates]]

the devil is truly in the details.



Consequently, here's an attempt at details.
Consequently, here's an attempt at details.

Revision as of 20:15, 29 May 2009

Carrying on the tradition of naming software via puns, I'll lay down some thoughts on how to answer the question:

When should our software automatically do risky thing X?

Background

People have been concerned with this question (and with variants and related questions) for some time:

<trac>5657</trac>, on spoofing-resistant update algorithms for de-isolated activities
questions on activity signing and update thread
activity semantics conversation
runtime build customization thread and <trac>6432</trac>
user-created activities and updates thread
horizontal distribution thread
homunq's ideas on bundles and updates

the devil is truly in the details.


Consequently, here's an attempt at details.