[Sugar-devel] Rainbow

[Bernie Innocenti]

On Wed, 2010-07-07 at 01:18 -0400, Michael Stone wrote:
> > XO and SoaS distributions are configured for sudo with no password.
> 
> Yes. However, Uruguay does not maintain this configuration choice.

I'm very sorry about this.


> > Rainbow has been bit-rotting for the past 2 years 
> 
> Ahem. Sugar's integration with rainbow has bit-rotted, been rebuilt, and still
> received no independent testing despite repeated calls for same.

Raul and I would have liked to resurrect Rainbow in time for F11-0.84,
and then for F11-0.88. We asked a couple of times about the current
packaging status and what patches still need to be applied in Sugar, but
it seemed that there was still too much integration work to be done.


> > and nobody volunteered to work on it. 
> 
> If you check the dates carefully, you'll find that most of my recent work on
> rainbow and rainbow/sugar integration has occurred while I was on vacation from
> my real job. So please do count that as "volunteer hours".

Don't get me wrong, your volunteer work to enhance Rainbow is much
appreciated, but it is not by itself sufficient to get Rainbow to work
again with Sugar.

There seems to be the need for someone who'd be willing to do the
missing integration work. People with both Sugar and Rainbow expertise
aren't that common.


> Sure. And if, by some miracle, Sugar ever becomes *worth* attacking [1], then
> we will all rue the day when we had the opportunity to make it safe and chose
> not to.

I wouldn't worry very much: the attack surface of Sugar from the public
Internet is very small: basically, just xulrunner. The LAN of an
elementary school is relatively free of advanced crackers. This leaves
out only unusual Sugar instances that are being used from home networks
connected directly to the Internet.

The worst attack vector I can think of would be a malicious activity. I
think this is pretty much the same threat of malicious Firefox plugins,
and it is being taken care of exactly in the same way. If it becomes

Perhaps I'm not being paranoid enough... but anyway, if the situation
worsens, we could always restore Rainbow and/or check gpg signatures on
installation, like most Linux distros do.


> > A non-privileged account can already effectively do anything that a spammer
> > would like to do.
> 
> And when will you be shipping my prctl(PR_DISABLENETWORK) kernel patch?
> 
> (Or have you a better approach?)

I thought the review got swamped on lkml a long time ago? Or maybe I was
dropped off the cc list... Last thing I know, there was disagreement
about what the correct approach was and some linux hackers derailed the
thread by invoking the stackable LSM bullshit.

What matters the most is that nobody thought that the scenario that your
patch was trying to address wasn't an interesting one. You might have a
chance to get *some* version of your patch approved if you aggressively
reply to the nonsense reviews asking the reviewer:

 - how would you do it instead?

 - does your alternative effectively address my use-case?

 - you and X sent conflicting feedback, please sort it out
   among yourselves and let me know which approach is preferred

 - who is the authoritative maintainer to ack a patch like this?

In a case like yours, the technical side of getting the patch right is
very easy compared to mediating among conflicting design goals.


> I am still much more satisfied with the approach taken by 0install. [2]

0install is a huge leap forward compared to the crap xo bundle format,
but still too much prototypal to cover half of our requirements.

The biggest flaw is that there's no well-defined build system to obtain
binaries from sources, so activities authors would have to setup
multiple environments and build manually for all the architectures we
intend to support. When you add a new architecture, it takes months or
years before most activities become available for it.

I've been advocating a proper build cluster for years. Now that OLPC is
working on an ARM-based platform, it will be clear to anyone why it was
needed.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/