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/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
