Re: XO memory size
On Monday 23 February 2009 04:48:52 pm qu...@laptop.org wrote: Sounds interesting. Which version of debxo? 0.4 Show us the output of /proc/meminfo. de...@debxo:~$ cat /proc/meminfo MemTotal: 221776 kB MemFree:174732 kB Buffers: 0 kB Cached: 19192 kB SwapCached: 0 kB Active: 13728 kB Inactive:10432 kB SwapTotal: 0 kB SwapFree:0 kB Dirty: 0 kB Writeback: 0 kB AnonPages:4988 kB Mapped: 6476 kB Slab:15064 kB SReclaimable: 1616 kB SUnreclaim: 13448 kB PageTables:660 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:110888 kB Committed_AS:14196 kB VmallocTotal: 810956 kB VmallocUsed: 19696 kB VmallocChunk: 790904 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 4096 kB ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 activity launch failure not recorded
2009/2/23 Mikus Grinbergs mi...@bga.com: I had the RoadMap Activity installed on my 800 system. I just updated (via manual 'sugar-install-bundle') to the latest version. Now it does not launch. The fault is likely to be mine - I either goofed the manual install, or should not have applied the latest-and-greatest to 8.2.1. Nevertheless, I expect that when an Activity fails to launch, there would be some sort of log made to help the user find out what went wrong. As far as I can tell, __NOTHING__ whatsoever got recorded about the launch failure. Sounds like you've found a bug, there should always be something logged. Perhaps you could file a ticket with olpc-log output attached? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: extra OATS keys
2009/2/24 Martin Langhoff martin.langh...@gmail.com: On Sat, Feb 21, 2009 at 3:23 AM, Daniel Drake d...@laptop.org wrote: We would like to set up a server in Paraguay (possibly hosted at the Have you got 100% connectivity in Paraguay? In schools, yes. The whole antitheft-server-in-the-sky model depends on that, and I am personalyl walking away from that model as soon as I can. My ruling assumption is that connectivity is available in some schools but not all. And that antitheft is important for all. Even though we have full connectivity we would also prefer to run this service from the XS, not requiring connectivity. We're only taking this route because we're too short on time to work on a proper implementation. My thinking is that if we have *some* kind of functional automated update system in place, we can use that to push an OS update including a nicer update system in future :) FWIW, Mitch kindly made a new keyjector with our t1 public key, so it looks like this is an acceptable path for now. I documented the designation of the 't' keys at http://wiki.laptop.org/go/Firmware_security#Multiple-Key_Support Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Wiki-gang] getting the truth about future releases onto wiki.laptop.org
2009/2/23 Samuel Klein s...@laptop.org: I believe joyride is working as designed at the moment and should be updated once 8.2.1 is quite out the door. That's not correct, at least nobody to my knowledge is working on joyride. It would be possible for someone to pick it up, but I doubt that will happen. S Page's wiki summary is accurate. At the developer meetings that have been held on this topic, it was agreed that joyride plus the processes that it represent would be scrapped, and OLPC plus interested community members would work towards getting everything upstream and then running pure Fedora (as in the OS, not as in their default installer shipment of GNOME) + Sugar on the XOs. This is already happening with impressive progress, although there is plenty of work to be done. By contrast, joyride has not seen any real activity for about 2 months. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: getting the truth about future releases onto wiki.laptop.org
2009/2/23 S Page i...@skierpage.com: 9.1.0 is cancelled, joyride does not incorporate latest Sucrose, O.S. development is taking place elsewhere. Such adjustments have made big chunks of wiki.laptop.org deceptive. AFAIK, no one has put this change in direction on the wiki (?!), so I jumped in. * I started with http://wiki.laptop.org/go/Future_releases , adding a new section == Next-generation releases will not come from OLPC == Thanks! I brushed it up a little and added some more information. Further tweaks are welcome. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New release8.2.1 build 801
2009/2/24 rihowa...@gmail.com rihowa...@gmail.com: Release 8.2.1 build 801 fails to connect to my AP (linksys WRT54g L ) . AP Icon starts to pulse then stops. Never connects. Worked fine with build 800 and with build 800 updated with q2e32. Seems unlikely to be an 801 regression, could you double check both versions? Also, are you using encryption or anything like that? If you're convinced it is an 801 regression then a ticked with olpc-log output (from 801 after connection failure, and from 800 after successful connection) would be appreciated. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
testing 8.2.1 - 800
I had some time lately and tested the latest signed release. I have reimaged (with 4 button pressed start) my XO and after that installed activities via olpc-update and some yum mc/gcc/make/X11-devel/Xv-devel. I did not copied my developer key to /security this time. The extreme power management is unchecked (the default setting). 1. While doing some yum list something on the virtual console my XO freezed and only could restarted by holding the power button for 5 secs. Nothing was written to the console (but it was the 2. console). The file what yum generated stopped abruptly halfway. 2. The wireless works as it did with 763 or something (I have never installed 767). It cannot connect to a Belkin PreN with WPA (100% displays the password dialog and no matter what I type into it the machine just redisplays the dialog). After I cancel the dialog then I can just click on the AP and it connects 100%. I do not really remember how did it work last year but it seems that I no longer have to wait until the XO stops scanning mesh networks (and it does not seem to stop it anyway). 3. After using the XO for 2 hours while developing some XVideo using applcation and closing the lid several times and stealing some unprotected wifi to browse the web (I was waiting in a hospital for 2 hours), I finally shutdowned the machine and it freezed with libertas: tx watch dog timeout. After I pressed the power twice to sleep and wakeup, the shutdown continued, displayed the shutdown screen and the the XO switched off. The error message was uploaded here: http://wiki.laptop.org/go/Image:Xo_freeze_on_shutdown.png So it is a regression since the old image was not used to crash or freeze during shutdown and the wireless seems to be just as broken as it was (probably the suspected network manager race condition what I was speculated lately). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 activity launch failure not recorded
Sounds like you've found a bug, there should always be something logged. Perhaps you could file a ticket with olpc-log output attached? There are two perfectly good existing tickets (#8861, #8834). My point was that this problem can still show up in 8.2.1. [Attached some log output to #8834.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] ActivityTeam meeting
On Tue, Feb 24, 2009 at 04:39, Wade Brainerd wad...@gmail.com wrote: Hi all, We are holding our second ActivityTeam meeting this Friday at 12pm EST (17:00 UTC). It should last 1 hour (the length of my lunch break). Hope to see you there! What: Activity Team meeting When: 27 February 2009, 12:00 pm EST Where: irc.freenode.net, #sugar-meeting Agenda: * Catch up on the past month's progress * activities.sugarlabs.org discussion Hi, I'm not sure if I will be able to make this meeting, but I would like to suggest some issues related to a.sl.o: ** Identify major issues that block usage by all activity maintainers and/or consumers. ** Make a clear howto about uploading a bundle, nominating it, etc. Could be a guide with screenshots or a screencast, etc (I think that David Farning is looking at this) ** Set up a team of administrators and a team of editors. I guess a couple of people in each could be a good start. Regards, Tomeu * Status of activity migration + author outreach * Review of the TODO list * Distribution discussion ** Minimum resolution supported by Sugar ** Help system * News from this Tuesday's OLPC Deployment meeting. Best, Wade ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: [Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
Michael Stone wrote: In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. Now that Sugar was made more modular, I think it's up to the individual distributors to make a choice. It might be enabled by default on XOOS, disabled by default on F11, and so on. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Is there any work that needs to be done Sugar side in order to adapt it to your refactored version of Rainbow? If so, I'm afraid that: 1) nobody but you understands Rainbow well enough to come up with a proper patch 2) it might be too late for the 0.84 release cycle at this point. P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. I'm with you on this. Actually, Rainbow is the only part of OLPC's security I find actually beneficial for the user. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] ActivityTeam meeting
On Tue, Feb 24, 2009 at 10:41 AM, Tomeu Vizoso to...@sugarlabs.org wrote: ** Identify major issues that block usage by all activity maintainers and/or consumers. ** Make a clear howto about uploading a bundle, nominating it, etc. Could be a guide with screenshots or a screencast, etc (I think that David Farning is looking at this) ** Set up a team of administrators and a team of editors. I guess a couple of people in each could be a good start. Thanks Tomeu, I added these to the agenda. Best, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form This can be implemented and I believe but have not confirmed which leave the reader unclear as to which services have actually been implemented. Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable. Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT. Or do you? Any exceptions? What about reading files elsewhere in the file system? The scattershot documentation within several wiki pages and text files of unknown currency is also a problem. How about a unified document befitting such an important aspect of the Sugar architecture. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. Carol Lerche On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone mich...@laptop.org wrote: On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: [Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- It is difficult to get a man to understand something, when his salary depends upon his not understanding it. -- Upton Sinclair ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
Michael, when several weeks ago you showed me in #sugar your patches to Sugar and explained the new rainbow concept, I told you that it seemed a good idea and that the patches looked pretty good. As you said Rainbow wasn't ready for 0.84, I told you that we would talk again when work on 0.86 starts. Which it hasn't yet, afaik. So I don't think you should feel sad because of our schedule. All projects need one and it's good to try stick to it. I will repeat that I think Rainbow can be a very important part of Sugar and that we should see how integration should happen, but I'm afraid I cannot directly help you with coding, etc because as you know I'm very tied with 0.84 right now. Hope it clarifies, Tomeu On Tue, Feb 24, 2009 at 17:24, Michael Stone mich...@laptop.org wrote: On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: [Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular desktops (I'm sometimes using vnc running under different UIDs for the same purpose). Sascha, Thanks very much for the kind reply; it's really helpful to hear that someone thinks this work is worth pursuing. What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is that you should teach jhbuild to compile and install rainbow, then apply my patches to sugar (rebasing if needed, since they're now two months stale): http://dev.laptop.org/git/users/mstone/sugar-toolkit http://dev.laptop.org/git/users/mstone/sugar then see what breaks. (Which might be everything, since, as I said, rainbow has never been tested w/ jhbuild.) In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with what you learn so that it becomes easier for others to assist. Michael P.S. - Let me know where more help is needed and I'll be happy to try to get you unstuck. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Rainbow in jhbuild would help debugging. I don't think I am along=e in using it as a development environment. -walter On Tue, Feb 24, 2009 at 12:09 PM, Michael Stone mich...@laptop.org wrote: On Tue, Feb 24, 2009 at 05:41:09PM +0100, Sascha Silbe wrote: On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular desktops (I'm sometimes using vnc running under different UIDs for the same purpose). Sascha, Thanks very much for the kind reply; it's really helpful to hear that someone thinks this work is worth pursuing. What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? Never having used sugar-jhbuild, it's hard for me to say precisely. My guess is that you should teach jhbuild to compile and install rainbow, then apply my patches to sugar (rebasing if needed, since they're now two months stale): http://dev.laptop.org/git/users/mstone/sugar-toolkit http://dev.laptop.org/git/users/mstone/sugar then see what breaks. (Which might be everything, since, as I said, rainbow has never been tested w/ jhbuild.) In the mean-time, let's start updating http://wiki.laptop.org/go/Rainbow with what you learn so that it becomes easier for others to assist. Michael P.S. - Let me know where more help is needed and I'll be happy to try to get you unstuck. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. But Michael, what you seem to be asking for - someone to pick up your solo project and finish it - almost never happens in software development. Code is a personal expression of the programmer who wrote it. If it ever does get finished by someone else, it likely gets rewritten in the process. Best regards, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Wade Brainerd wrote: To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. Users naturally want to do this. To see what happens when the operating system doesn't support it, just look at the wave upon wave of e-mail viruses that plagued Windows for so many years. Without support for safe collaborative development of this sort, Sugar has little to recommend it over XFCE and similar gtk-based iconic user interfaces. We are getting there, and with the latest improvements to view-source and Rainbow, we are beginning to have the basics in place. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi Carol, you make it sound as if Rainbow was new and unknown and Michael was pushing it. That's a bit unfair. Rainbow has been shipping in the OLPC releases for quite a while, and activity authors in general do know that they simply have to respect the designated directories for saving files. For example, they do know that SUGAR_ACTIVITY_ROOT (provided by Rainbow for runtime use) is something else altogether than SUGAR_BUNDLE_PATH (set by Sugar to the installation directory). Rainbow is one of the most generally useful things brought into being by OLPC. Since Sugar activities were specifically designed to work with it, it would be a shame to not use this enhanced security framework. In particular since Sugar aims at users who need all the protection they can get. Integration with jhbuild has been problematic since the rainbow demon needs to run with super user privileges, and it would need to mess with the user management of the host machine. But it should work very well in SoaS and I for one would appreciate if it was integrated and enabled there. - Bert - On 24.02.2009, at 17:56, Carol Farlow Lerche wrote: Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form This can be implemented and I believe but have not confirmed which leave the reader unclear as to which services have actually been implemented. Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable. Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT. Or do you? Any exceptions? What about reading files elsewhere in the file system? The scattershot documentation within several wiki pages and text files of unknown currency is also a problem. How about a unified document befitting such an important aspect of the Sugar architecture. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. Carol Lerche On Tue, Feb 24, 2009 at 8:24 AM, Michael Stone mich...@laptop.org wrote: On Tue, Feb 24, 2009 at 01:47:01AM -0500, Mikus Grinbergs wrote: [Also, I'm hearing whispers of 'no Rainbow' after Joyride.] Mikus, In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, and by writing Sugar patches which cause Sugar to use it. Unfortunately, in the two months since I announced this work: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html and since I spoke about it at Fudcon Boston in January, I have received no feedback more serious than a (kind) thank-you note from Walter, let alone testing, bug reports, or patches. As you might imagine, this overwhelming response leaves me more than a little bit discouraged. Now, it could certainly be the case that there's more work that I need to do in the form of documenting, testing, or pushing my recent rainbows before people will be excited about trying them out and, if that's the case, someone should tell me. Since no one has done so to date, despite repeated overtures, I've mostly come to believe that no one cares. Do you know differently? Michael P.S. - I find this state of affairs particularly sad, since I think there's an /increasing/ amount of awesomeness that Rainbow can provide, e.g., bringing all the recent hard work the kernel folks have been putting in on network containerization and memory-resource cgroups to the masses. ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: To me, Bitfrost was just one more lofty windmill OLPC tried to tilt because it seemed like an interesting challenge. So you've said in the past. What of it? I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. The justification which interests me the most goes something like: strong protections mean that there is less risk that kids and teachers will break things by installing software on their machines; therefore, educational innovations will spread faster. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. There is no reinvention taking place here; instead, we are using both long-standing OS features (discretionary access control; memory isolation) and novel OS features (network containerization, cgroup-based memory resource limits) in new combinations as they become available. What has changed is that the Sugar UI and user expectations permit concentrated use of these features. That said, Rainbow exists, so we don't need to do anything to remove it. So long as people step up to maintain it and help activity developers fix the issues they run into. The issue is that rainbow has been maintained and its downstream users (e.g. Sugar) need to give some feedback on the intermediate results so that there will be time for its upstream author to respond to that feedback. But Michael, what you seem to be asking for - someone to pick up your solo project and finish it Thank you, no. I apologize if my writing contributed to this gross misunderstanding of my purpose. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:57 PM, Michael Stone mich...@laptop.org wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. The justification which interests me the most goes something like: strong protections mean that there is less risk that kids and teachers will break things by installing software on their machines; therefore, educational innovations will spread faster. See my comment regarding Backup, a far more useful and achievable solution to this problem. Reinventing the desktop as a constructivist learning environment is a big enough task for one development team / community to swallow. Reinventing security is an altogether separate cause. There is no reinvention taking place here; instead, we are using both long-standing OS features (discretionary access control; memory isolation) and novel OS features (network containerization, cgroup-based memory resource limits) in new combinations as they become available. What has changed is that the Sugar UI and user expectations permit concentrated use of these features. In a nutshell, all this refers to Sandboxing, which seems to be the new hotness in software security these days. I type this email in Google Chrome, which is a good example of that. There's nothing wrong with sandboxing or other new security techniques, I just argue that their purpose is *orthogonal* to the goals of Sugar. Apologies for incorrectly assuming that you wanted someone to finish Rainbow. As far as I know the current implementation is without major issues, if some of the more advanced features of Bitfrost are not yet implemented. Regards, -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Bert, Are you satisfied with the number of activity developers? Are you satisfied with the number of developers within the deployments? Have you noticed the periodic questions on the developer-oriented lists about Rainbow security and whether it is causing mysterious symptoms? I'm not, and I have. Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), Things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: Bert, Are you satisfied with the number of activity developers? Are you satisfied with the number of developers within the deployments? Have you noticed the periodic questions on the developer-oriented lists about Rainbow security and whether it is causing mysterious symptoms? I'm not, and I have. I am virtually certain that Rainbow is not the major obstacle to getting more activity developers. Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), . the relevance of APIs versus packaging elements versus choices by the sugar shell/infrastructure developers, . things that the activity developers can and can't do (given that I, at least, hope that new developers will participate, who have preconceptions from other environments), Things that are hoped for in future development (well delimited from things that are there now.) Good documentation is hard, and wiki pages are only good documentation if the wiki is maintained with great discipline (which I fear is not the case at w.l.o). But for a subtle and complex feature such as Rainbow, good documentation would be a motivator for use both within and outside the sugar community. Agreed. However, what activity authors need to know about rainbow is documented, and it really is not much. For example, here http://wiki.laptop.org/go/Low-level_Activity_API#Security This is not even a full page, and if activity authors use the Python Sugar toolkit they can worry even less about this. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 08:56:06AM -0800, Carol Farlow Lerche wrote: Michael, I think your work on Rainbow is very important, but I think it is a bit opaque. Carol, Thanks you for this detailed critique of my documentation efforts to date. One thing that I've (obviously) struggled with is understanding which audiences require which sorts of documentation. Your continued assistance untangling this mess is most appreciated. Perhaps you could improve your documentation and as well write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. I'll see what I can cook up. So here's an example. In the Rainbow page on w.l.o you refer to http://dev.laptop.org/git?p=security;a=blob;f=rainbow.txt;hb=HEAD for more information. Yet this file has several locutions of the form This can be implemented and I believe but have not confirmed which leave the reader unclear as to which services have actually been implemented. Do you have an example of documentation which you think really nailed the divide between what is needed, what exists, how good is it?, and how do I use it? Hopping over to Low-Level Activity API the information about security doesn't correlate with the permissions referred to in the txt file. The purpose of the rainbow.txt document was to argue that a design /existed/ which would satisfy enough of the overall goals to be worth pursuing. The purpose of the Low-Level Activity API documentation is to explain what features of rainbow exist and can be twiddled by activities. As it happens, the main feature which exists is primitive filesystem isolation. Also you leave ambiguities for the reader by using the passive voice throughout these articles. Changing from passive to active voice answers many questions for the reader. Here is an example: All writing to the file system is restricted to subdirectories of the path given in the SUGAR_ACTIVITY_ROOT environment variable. Well, we know that isn't true in all cases, because activities get installed by Sugar outside that subtree. So possibly you mean Rainbow prevents any activity launched by the Sugar shell from writing to any directories except those under SUGAR_ACTIVITY_ROOT. Or do you? Any exceptions? What about reading files elsewhere in the file system? For me, these questions are largely answered by the statements, scattered throughout the system, that rainbow operates by inventing new uids for programs which it is asked to isolate. However, I can certainly lay things out more explicitly. Thank you for the reminder about active vs. passive voice. I think demystifying Rainbow within a comprehensive document containing a section specifically aimed at the concerns of activity developers would go a long way toward expanding its use. What are the concerns of activity developers? To date, the only one which I have heard clearly articulated is: How do I turn rainbow off for testing? which, in fact, is answered in the For Activity Developers section. http://wiki.laptop.org/go/Rainbow#For_Activity_Developers Obviously, a couple of people also found it helpful to tweak the isolation options in detailed ways as discussed in the API docs you cited earlier. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Carol Farlow Lerche c...@msbit.com wrote: things that the activity developers can and can't do As an aside, I yesterday uploaded a simple activity to addons.sugarlabs.org. This activity runs on os767 and soas (afaik). Your post and this discussion made me realize that I hadn't had to think about Rainbow *at all* and things Just Worked. For simple activities and/or barrier-to-entry discussions, that observation seems germane. Martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
bert wrote: On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: ... Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), for my part, i've always felt that it's this first point of carol's that's been missing from the docs. the functional overview is very important: as a developer, you're asking me to implement a bunch of new API functionality simply to make a simple program (which may already be working well in most other unix environments) functional. i'd like to be sold on the concept first, before having to do a bunch of work for no (apparent) benefit to me or my program. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 1:30 PM, p...@laptop.org wrote: bert wrote: On 24.02.2009, at 19:09, Carol Farlow Lerche wrote: ... Asking for better documentation doesn't imply that the facility is new. It recognizes that development has reached a local minimum in an important component that is not well understood by many. My post was a request to the most knowledgeable person, Michael to do the service of taking the time to write a document that clearly lays out . the purpose (not in security speak but in terms of the benefits it brings to end users), for my part, i've always felt that it's this first point of carol's that's been missing from the docs. the functional overview is very important: as a developer, you're asking me to implement a bunch of new API functionality simply to make a simple program (which may already be working well in most other unix environments) functional. i'd like to be sold on the concept first, before having to do a bunch of work for no (apparent) benefit to me or my program. I'm going to bow out of this thread (back to work!) but I wanted to bring up one last point regarding Rainbow's cost to Sugar. It is my sincere hope that sometime in the future Sugar will gain the ability to seamlessly launch normal X applications alongside activities. There are a great many educational Linux applications out there that would fill in gaps in our activity lineup. I fear that Rainbow will be an obstacle to achieving this goal, as we don't have the ability to fix every application in existence to conform to our non-standard security model, and emulation hacks will never just work. Best, Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
--- Wade Brainerd wad...@gmail.com wrote: Backup, a far more useful and achievable solution to this problem. I don't see how Rainbow, something _working_ and pretty usable on my XO right now, is usefully compared to backup, a solution similar in specificity to the aphorism be careful and one that doesn't resemble anything working on my XO right now. I think there are about a ton of threads about how backup might be implemented on {,xs-}de...@l.o. Regards, -Wade Martin ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
Hi Michael, 2009/2/24 Michael Stone mich...@laptop.org: In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. How realistic is it to make rainbow something generic that all environments and applications could use? In an ideal world, such a security system should be available to everyone, not just sugar users -- but I'm not sure which technical challenges are entailed. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 8.2.1 activity launch failure not recorded
2009/2/24 Mikus Grinbergs mi...@bga.com: Sounds like you've found a bug, there should always be something logged. Perhaps you could file a ticket with olpc-log output attached? There are two perfectly good existing tickets (#8861, #8834). My point was that this problem can still show up in 8.2.1. OK, thanks! In future, it's helpful to have such information in the first mail (not a regression, seen it before, here are the trac ids). Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Michael, I'm happy to continue this discussion off-list if you or others feel it is inappropriate to carry it on here. However, to respond to your mail: Thanks you for this detailed critique of my documentation efforts to date. One thing that I've (obviously) struggled with is understanding which audiences require which sorts of documentation. Your continued assistance untangling this mess is most appreciated. I would be happy to supply detailed editorial comments to any effort you make to provide a unified Rainbow document. ... write a tutorial about it that would make it more apparent how much is actually implemented and what an activity can do with it. I'll see what I can cook up. You might consider: Specifically list aspects of program operation that are forbidden or limited in the application, by default, under the current implementation. Tell why the restriction is there, from a user-benefit perspective. If these restrictions can be overcome by configuration files or programmatic calls, list these under the restriction description. Point out explicitly where a developer would see evidence of the restriction being called into play (which log, e.g., and where is it? Do you need to turn on logging in some way to see the messages?) You might want to create a separate tutorial from the standpoint of other desktop environment developers, along the lines of what to do to implement Rainbow in your environment. I already here voices chiming in that all anyone needs is to read the code. But could those chiming voices please recognize that there is a difference between the effort people will go to in conforming to or using a feature that they don't entirely belive in, (rather than just turning it off) compared to being provided easy access and understanding. Do you have an example of documentation which you think really nailed the divide between what is needed, what exists, how good is it?, and how do I use it? It is uncommon to document future features unless they are realistically expected to be implemented soon, except perhaps as an appendix of unresolved issues, or bugs sections as in man pages. But frequently documentation addresses features that are only present in later versions. Often this is set off by color, inline images of some kind or similar visual cues. As it happens, the main feature which exists is primitive filesystem isolation. Well, I'd stick to documenting that, and save the blue sky for an appendix. For me, these questions are largely answered by the statements, scattered throughout the system, that rainbow operates by inventing new uids for programs which it is asked to isolate. However, I can certainly lay things out more explicitly. Thank you for the reminder about active vs. passive voice. Persons with a deep or even a moderate interest in security would understand that that was the case, but we're talking about a hoped-for community of activity developers including educators and learners that have so far proved unable to cross a rather high barrier of entry. What are the concerns of activity developers? To date, the only one which I have heard clearly articulated is: How do I turn rainbow off for testing? which, in fact, is answered in the For Activity Developers section In this case, perhaps we should contemplate why someone would want to turn off rainbow, rather than using information that tells them what Rainbow is preventing. Can I offer the analogy of the dreaded Windows security problems in which applications written for early versions of Windows silently broke when MS introduced new access violation error returns that the programs were unaware of? These errors could often be eliminated by end users through granting constrained privileges to various Windows resources, but instead most people just did the simple thing. They ran the application as administrator (analogous to turning Rainbow off). All the bad consequences followed. Btw I don't think it was just that developers turned off Rainbow. Users did too, because activities had been written outside the context of Rainbow, then it was turned on. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, 24 Feb 2009, Carol Farlow Lerche wrote: . the purpose (not in security speak but in terms of the benefits it brings to end users), also why should rainbow be used instead of one of the many other sets of tools available to distros for locking down a desktop (SELinux, or other LSMs)? can/should rainbow be modified to use the LSM hooks so that it can be used with standard systems? or is it really doing something that is Sugar specific? how should/could rainbow work with non-sugar apps? (normal X learning apps running on an XO to use an example raised in another post in this thread) how should/could apps work around what seems like a rainbow limitation to let one binary be used for multiple 'apps' (for example gmail + browse or the X desktop wrapper) I apologize if you already answered this in your documentation, but these sorts of concepts were not even being discussed a year or so ago, and the answers are not generally known. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 03:45:33PM -0300, Daniel Drake wrote: Hi Michael, 2009/2/24 Michael Stone mich...@laptop.org: In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. How realistic is it to make rainbow something generic that all environments and applications could use? I consider it a realistic goal, with a few caveats. The rainbow-0.8.* redesign takes a big step in this direction by introducing an exec-wrapper interface which can be embedded in fd.o .desktop launchers, used from the CLI, and used by custom launchers like Sugar with equal ease. Privilege is acquired from a setuid helper; e.g. sudo. The design and automated tests now support limited concurrent multi-user operation, though the implementation needs a bit more work in order to operate securely in a multi-user environment. The only notable dependencies so far are on python and glibc. The caveats are: a) Usability sucks at the moment. For example, I need to implement some sort of garbage collection and some kind of user-facing UI, which might just be a simpler CLI wrapper. I probably also need to write a man page and to introduce more diverse error codes. b) We're going to need recent kernels for the fancier containerization stuff that I'd like to work on in the future. (Fortunately, upstream seems to be making good progress on the features I want :) c) I don't have any good idea how well or poorly the current design scales. (I think it will work fine for desktop use. I'm just not sure how far beyond that it will stretch.) More questions? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] @a...@...?
Martin (and friends), Here is what is now happening: 1. I can ping the server from the XOs 2. I can ping the XOs from the server 3. We updated the DNS server to include our schoolserver hostname. 4. The XOs can ping the server using the hostname. Here is what is NOT happening: 1. When I go to the XO Control Panel and select Register, I get an error saying that the server cannot be found. What can I do now? Thanks. Gerald Ardito On Mon, Feb 23, 2009 at 6:28 PM, Martin Langhoff martin.langh...@gmail.comwrote: Hi Gerald! On Tue, Feb 24, 2009 at 10:16 AM, Gerald Ardito gma...@gmail.com wrote: The problem I am having now is that when I go to Register the laptops, I get an error message that the server cannot be found. I can ping the server from the XOs and vice versa, so I am not sure what is happening. From the laptops you should be able to - ping schoolserver - connect to schoolserver on port 8080 - try telnet schoolserver 8080 - you may need to install the telnet rpm cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] @a...@...?
Martin, I installed telnet and tried to connect via port 8080. The message back was connection refused. What next? Thanks. Gerald On Mon, Feb 23, 2009 at 6:28 PM, Martin Langhoff martin.langh...@gmail.comwrote: Hi Gerald! On Tue, Feb 24, 2009 at 10:16 AM, Gerald Ardito gma...@gmail.com wrote: The problem I am having now is that when I go to Register the laptops, I get an error message that the server cannot be found. I can ping the server from the XOs and vice versa, so I am not sure what is happening. From the laptops you should be able to - ping schoolserver - connect to schoolserver on port 8080 - try telnet schoolserver 8080 - you may need to install the telnet rpm cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24.02.2009, at 20:43, Sascha Silbe wrote: On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. It's not that Sugar needs more protection than currently existing desktop environments, but rather that _all_ desktop environments need it (but currently lack it). In fact, I hope that other DEs will start using Rainbow as well, even if just optionally. +1 Besides, if we didn't feel that children deserved better than the currently popular systems we would not have started Sugar development in the first place. Security is one aspect of this. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Hi, On Dienstag, 24. Februar 2009, Wade Brainerd wrote: Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Ahem, sugar is aimed at kids, not at people developing software or learning how to do system administration. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. It seems to me your hammer is called backup. ;-) regards, Holger, who thinks that rainbow is extremly needed signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Volunteer Infrastructure Group meeting today, irc.oftc.net:#olpc-admin February 24, 2009 4:00 pm EST -05:00 UCT
Volunteer Infrastructure Group meeting today, irc.oftc.net:#olpc-admin February 24, 2009 4:00 pm EST -05:00 UCT Agenda is posted at: http://wiki.laptop.org/go/OLPC:Volunteer_Infrastructure_Group#Agenda_for_next_meeting --HH. -- Henry Edward Hardy http://www.linkedin.com/in/henryhardy ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On 24 Feb 2009, at 17:52, Wade Brainerd wrote: On Tue, Feb 24, 2009 at 12:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: They are a single, indivisible cause, and also the entire reason for the existence of Sugar. Many operating systems provide users with a set of powerful tools for manipulating ideas and data. Sugar's purpose is to add another dimension: to encourage users to modify and share the tools themselves. To that end, if my friend sends me a modified copy of an activity, I must be able to run it without fear of wrecking my system. On the contrary, learning to develop software is almost impossible without wrecking your system once or twice. Backups are the correct solution to this problem, not some crazy security system. When all you have is a hammer, everything looks like a nail. I do very much agree about back-ups (Martin's and others school-server back-up work is in invaluable here), but the promise of Rainbow is not just about limiting the possibilities for how a system could get accidently/maliciously wrecked. For instance, how do you like the idea of 'a friend' silently harvesting all the Journal photos your kid has taken via a compromised/modified activity**? **actually Pippy and the slideshow example really creeps me out for just that reason – remind me, Pippy's getting special case hack permission to drive a 8 line highway through Rainbow security permissions, right? I know Rainbow, as currently implemented, is lacking in certain areas – but Rainbow is providing something I think is valuable, that's not available elsewhere, and in a manor appropriate for the non-specialist target audience. --Gary P.S. Maybe I'm just paranoid; v.happy to be corrected. -Wade ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 11:24:37AM -0500, Michael Stone wrote: http://lists.sugarlabs.org/archive/sugar-devel/2008-December/010528.html Thanks for your work! I sure hope it'll get used instead of dropped, it's the #1 reason I looked into Sugar in the first place and the one thing I miss most on regular desktops (I'm sometimes using vnc running under different UIDs for the same purpose). What exactly do I need to do to try it out within sugar-jhbuild on Ubuntu intrepid (amd64)? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 12:29:57PM -0500, Wade Brainerd wrote: I'm not clear why Sugar needs more protection from rogue activities than a normal desktop environment has from rogue applications. It's not that Sugar needs more protection than currently existing desktop environments, but rather that _all_ desktop environments need it (but currently lack it). In fact, I hope that other DEs will start using Rainbow as well, even if just optionally. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 5:24 AM, Michael Stone mich...@laptop.org wrote: In my view, it's up to the SugarLabs folks to use Rainbow or to drop it. I have tried to clear the way for them to use it on all the platforms they care about by simplifying it, by making it more generically useful, by writing some basic .deb and .rpm packaging in order to ease testing, Hi Michael, what rainbow provides is very important. The trusted-OS checks from the firmware up are important. The userland application privilege isolation is hugely important, as we are pushing for making our apps heavily network oriented, the risks of other network hosts trying to take advantage of vulnerable apps is huge. You are now talking about the implementation of rainbow that provides userland privilege isolation. One thing that I wonder is whether in the push to make our OS more generic it would make sense to push rainbow in the direction of things like smack or selinux. Maybe rainbow could insta-isolate creating selinux profiles for activities? Maybe my ignorance on matters selinux is showing? ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Martin Langhoff wrote: Maybe my ignorance on matters selinux is showing? ;-) You are not alone. Sugar/OLPC simply never had SELinux experts who volunteered to work on Rainbow. We still don't (raise your hand if you consider yourself proficient at writing SELinux policy!). It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified secure to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. --Ben P.S. The SELinux entry on Wikipedia contains the following gem: Isolation of processes can also be accomplished by mechanisms like virtualization; the OLPC project, for example, sandboxes individual applications in lightweight Vservers. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, 24 Feb 2009, Benjamin M. Schwartz wrote: Martin Langhoff wrote: Maybe my ignorance on matters selinux is showing? ;-) You are not alone. Sugar/OLPC simply never had SELinux experts who volunteered to work on Rainbow. We still don't (raise your hand if you consider yourself proficient at writing SELinux policy!). So does anyone want to become expert at writing SELinux policy? Someone who might benefit from a Red Hat internship in Westford at the feet of the master of SELinux, Dan Walsh? http://danwalsh.livejournal.com/26904.html --g -- Got an XO that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 11:33:30AM +1300, Martin Langhoff wrote: You are now talking about the implementation of rainbow that provides userland privilege isolation. For the record, rainbow only describes the userland privilege isolation part. The rest is just OFW, olpcrd, olpc-update, OATS (If somebody knows a better way to explain this stuff, speak up!) One thing that I wonder is whether in the push to make our OS more generic it would make sense to push rainbow in the direction of things like smack or selinux. I think this would have the effect of making rainbow much less generic than it currently is. On the other hand, it might still be worth doing if it made it much easier to implement important features. Maybe rainbow could insta-isolate creating selinux profiles for activities? I've been wondering about this for some time. Basically, while my reaction when it was initially proposed it was lukewarm, for all the usual reasons [1]. Since then, I've been very gradually warming to the idea, in part as SELinux matures, in part as I get to know the technology and people [2] better, and in part as I run up against limitations of the simple Unix approach that I've taken for the last year. Therefore, while it's not how /I/ intend to proceed in the near future, I'm happy to try to work with people who feel differently. I definitely have some ideas on the subject. Michael [1]: http://lists.laptop.org/pipermail/security/2008-January/000370.html [2]: http://danwalsh.livejournal.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 06:05:51PM -0500, Benjamin M. Schwartz wrote: Sugar/OLPC simply never had SELinux experts I'm pretty sure this is false. For instance, I know that ancient OLPC+RH kernels has SELinux enabled and I know that the SELinux folks at RH have always been excited to help me to understand their work whenever I took the time to ask them questions every few months. It's hard to write a sandboxer like Rainbow, since it must not only appear to work, but be verified secure to a high degree of confidence. That's harder still if one is writing in a system in which one is a novice, so the developers (principally Michael) have instead stuck to technologies with which they are already expert. This is actually not such a big deal, in my opinion. The killer problem, as I learned from the vserver experience, is that novice activity authors /must/ be able to debug their work in any system which we might hope to ship. I don't think that I have very good ideas on how to make this part workable with technologies that are more complicated or more obscure than Unix DAC. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Tue, Feb 24, 2009 at 10:22:07PM +, Gary C Martin wrote: remind me, Pippy's getting special case hack permission to drive a 8 line highway through Rainbow security permissions, right? Unfortunately, no. No one has yet completed an implementation of the gates needed to guard access to the DS and the glue needed to know which DS entries to fork over to which activities. (I got partway through an implementation of the gates, which are actually fairly simple, but didn't get to the glue. [8.2.0 intervened.] Later, Scott approached the problem from a completely different angle, i.e. with FUSE filesystems. Hopefully, though, Tomeu's simplified data store will make further work in this area a bit simpler, if any such work occurs.) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] XS-rsync: automatic .contents creation
2009/2/24 Martin Langhoff martin.langh...@gmail.com: On Wed, Feb 25, 2009 at 2:48 AM, Daniel Drake d...@laptop.org wrote: 2009/2/23 Martin Langhoff martin.langh...@gmail.com: Can you flesh out the use cases a bit more? As Ties pointed out, it's related to .toc contents files (which XS-rsync calls .contents) and not content bundles. Colour me confused. What's the use case where the XS builds a special local image? There's no use case there. That's not what I'm suggesting. I'm describing the process of transferring the image (built on another system) to the XS for serving to the XOs. The XS-rsync readme states that 4 files are required: 1 xyz_jffs2-tree.tar.bz2 # tar.bz2 build img 2 xyz_jffs2-tree.tar.bz2.md5 # md5 of the tarbz2 3 xyz_jffs2.contents # json-encoded manifest 4 xyz_jffs2.name # file containing the name This mail is about (3). H. The way you're describing it makes me think that .contents still belongs in the image-preparation stage. Maybe fold the relevant bits of code into your script? It's possible, but I already explained why it's a bit painful. I see where you're coming from though, just thought I would ask! Daniel ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
On Wed, Feb 25, 2009 at 12:21 PM, Michael Stone mich...@laptop.org wrote: For the record, rainbow only describes the userland privilege isolation part. You're right. I conflated the overarching shadow of bitfrost with rainbow. My bad. I think this would have the effect of making rainbow much less generic than it currently is. I'm intrigued by your comment. Do you mean less portable, and in that case what kind of portability are you thinking of? selinux does look more generic than rainbow... And we don't have to go own the selinux path. Is smack simpler, more appropriate to our needs? As you say, selinux, smack and friends have moved forward a lot in the last 2 years. Implementation/documentation/understanding of them has matured enormously. Just having 'permissive' mode is a fantastic thing when developing sw. cheers m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Future of Rainbow + Sugar?
Tomeu Vizoso wrote: Michael, when several weeks ago you showed me in #sugar your patches to Sugar and explained the new rainbow concept, I told you that it seemed a good idea and that the patches looked pretty good. As you said Rainbow wasn't ready for 0.84, I told you that we would talk again when work on 0.86 starts. Which it hasn't yet, afaik. So I don't think you should feel sad because of our schedule. All projects need one and it's good to try stick to it. I will repeat that I think Rainbow can be a very important part of Sugar and that we should see how integration should happen, but I'm afraid I cannot directly help you with coding, etc because as you know I'm very tied with 0.84 right now. I think, this describes quite well the current where we stand currently regarding inclusion of Rainbow. I think it is an interesting part to tackle for 0.86. This release cycle was, in terms of changing resources and environment conditions, even worse than the last one. I guess, it can always get worse ;D So there was only so much we could do - and many things that fell of the plate. Anyhow, let's try to look forward - and see what we can do for 0.86. Thanks, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] XS-rsync: automatic .contents creation
On Tue, Feb 24, 2009 at 8:06 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Feb 24, 2009 at 4:12 AM, Daniel Drake d...@laptop.org wrote: If the XS shipped olpc-contents (http://xs-dev.laptop.org/~cscott/repos/joyride/olpc-contents-2.5-1.i386.rpm) then it would be easy to make XS-rsync be able to generate the .contents file automatically from the .tar.bz2 tree file. Interesting idea. Not sure I understand it fully. It sounds to me like it'd be useful to wrap up content created or aggregated online on the XS (using Moodle, for example) -- content that you want to bundle up for download to the XOs. Yes, I'd also like this included. Martin, my guess is you're confusing concepts. The .contents or .toc file is used when updating or flashing an XO image, for example by olpc-update to verify the stuff that's now on the XO is the stuff that's expected. Or perhaps you're forseeing other uses. The way to create a .contents file right now is damn right dirty. You basically chroot into the fs tree of an XO on the server and use the contents manifest builder which is present in every standard XO. That's what we're doing now in any case, and that's what Pilgrim does. If one can believe the Pilgrim inline documentation, this was done this way because Python 2.5 (often?) wasn't available on the servers at the time. And I'm just lazy. /Ties I'm not sure that it'd help with the backups/restore workflow. AFAIK, a content bundle will appear as one entry in your journal if it's able to unpack into separate entries in your Journal, then you're hit gold with your thinking. Is it possible to include that RPM, and would such patches be considered? Anything that is useful in deployments I'm happy to include :-) - just need to flesh out how it's useful to more/most rather than a bespoke trick. Can you flesh out the use cases a bit more? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] XS-rsync: automatic .contents creation
On Wed, Feb 25, 2009 at 2:48 AM, Daniel Drake d...@laptop.org wrote: 2009/2/23 Martin Langhoff martin.langh...@gmail.com: Can you flesh out the use cases a bit more? As Ties pointed out, it's related to .toc contents files (which XS-rsync calls .contents) and not content bundles. Colour me confused. What's the use case where the XS builds a special local image? The use case for xs-rsync serving content for olpc-update is for OS upgrades, which are generated in various formats by the team that manages the XS/XO infra at a central location, tested, some of the formats are signed (for NAND-flash updates), and so on and so forth. The XS generating its own images _locally_ is not something I considered. It sounds risky - serving a botched image will... botch XOs!.. that's why the unpack the tar part of the xs-rsync scripts is so anally paranoid. Sorry to sound repetitive... what's the use case? In future, we would like to use the same tool to build an image suitable for the XS to distribute using XS-rsync. 2 changes are needed to the image builder process for this to happen: 1. it should optionally output a tarball (in addition to, or instead of a jffs2 image). trivial modification to the script. 2. we need a .contents file, because XS-rsync requires that Right now, image builder is a nice standalone script without any painful dependencies, but generating the .contents file for (2) is a bit tricky. It would require installation of olpc-contents on the local system, which really means packaging for various distributions etc. It would be nicer if the server could create the .contents file for itself, which would not be hard. It even seems to unpack the tarball already for other reasons. H. The way you're describing it makes me think that .contents still belongs in the image-preparation stage. Maybe fold the relevant bits of code into your script? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] XS-rsync: automatic .contents creation
Hi Dan, As Ties pointed out, it's related to .toc contents files (which XS-rsync calls .contents) and not content bundles. The xs-upserv script knows how to create a contents file given an exploded directory tree -- is that what you're looking for? http://dev.laptop.org/git?p=users/cjb/xs-rsync;a=summary - Chris. -- Chris Ball c...@laptop.org ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall enhancements
On Mon, Feb 23, 2009 at 8:27 AM, Jerry Vonau jvo...@shaw.ca wrote: Wow, did I have a fun night for once, sorry for the delay in replying. :-) That should of read --baseurl=file:///mnt/isodir/updates I am a bit lost -- you do run a bit too fast. Or maybe erlang cooked my noodle... I've uploaded a XSupdates.zip to http://members.shaw.ca/jvonau/pub/0216/ Just unpack the zip to your usbdrive and add the line in sample.ks to the top of the present ks.cfg file on the usbdrive. The installer should add the repo into its repo setup routine and be available for the install. Will review. How did you prepare the files? What's the magic? This look like it maybe useful to rollout incremental changes to the base rpms, instead of installing, then yum updating we could packages up the newer rpm files for use with this updates repo and have them installed from the get go. We could add a createrepo routine to mkusbinstall to create a blank repo in updates off the bat and leave the repo line in the ks.cfg file, should have no ill effects if there is nothing present in the repo. Sounds evil. How about people who burn the iso? Or a deployment that drives anaconda-over-nfs or similar? If we make mkusbinstall really smart, we leave behind everyone who isn't using usb ;-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] mkusbinstall enhancements
On Wed, 2009-02-25 at 14:47 +1300, Martin Langhoff wrote: On Mon, Feb 23, 2009 at 8:27 AM, Jerry Vonau jvo...@shaw.ca wrote: Wow, did I have a fun night for once, sorry for the delay in replying. :-) That should of read --baseurl=file:///mnt/isodir/updates I am a bit lost -- you do run a bit too fast. Or maybe erlang cooked my noodle... Anaconda by default mounts the usb key at /mnt/isodir, I've just made another repo available on the usb in /updates. In order to enable this repo you need to add the repo line to the ks.cfg file I've uploaded a XSupdates.zip to http://members.shaw.ca/jvonau/pub/0216/ Just unpack the zip to your usbdrive and add the line in sample.ks to the top of the present ks.cfg file on the usbdrive. The installer should add the repo into its repo setup routine and be available for the install. Will review. How did you prepare the files? What's the magic? I just ran createrepo . in the directory, and zipped it up. Could be used to add local content. This look like it maybe useful to rollout incremental changes to the base rpms, instead of installing, then yum updating we could packages up the newer rpm files for use with this updates repo and have them installed from the get go. We could add a createrepo routine to mkusbinstall to create a blank repo in updates off the bat and leave the repo line in the ks.cfg file, should have no ill effects if there is nothing present in the repo. Sounds evil. How about people who burn the iso? Or a deployment that drives anaconda-over-nfs or similar? If we make mkusbinstall really smart, we leave behind everyone who isn't using usb ;-) cheers, This is for usb ATM... To add file to an iso, mkslim could do that, while a change to the repo line would be needed(I'd need to work up the syntax). NSF would be a snap, uses the same logic as harddrive to fine an iso. I'd just add the /updates to the root of the export, might just work with out changing the repo line, but I would have to mock that up to be sure. Sorry got to leave for work, back in 12 hours Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel