Re: [IAEP] Long-term support for Sugar
El Mon, 21-09-2009 a las 16:33 -0400, Bill Bogstad escribió: > The lack of good dependency reporting and version tracking for > Activities makes this difficult. Something like XO bundles could > work better for for some scenarios though. If it were on me, I'd just ditch the XO bundle format and use native packages for each distro. Some are already being packaged, and the Python distutils are capable of producing rpms and debs with the same ease of our current setup.py scripts. It's been discussed several time, but the consensus seems to be that the XO format will stay around for a while :-( > For example, has anyone ever done anything with the 'host_version' > field in the Activities *.info file? Maybe it could be hijacked for > Sugar library dependencies. Not as remotely capable as full dependency > checking, but core Sugar (glucose) could at least use this for direct > Activity dependency issues. Preferentially with a pop-up telling > people there may be incompatibilities. Activities that stick with > direct Sugar supplied functionality would be safe. Glucose would know > what range of values it supports and would alert if an Activity is > outside of that range. Activities would request the minimum value > that works for them in their info file. Perhaps Activities could also > query for the maximum value supported and change their behavior based > on it. (This assumes that Glucose functionality is monotonically > increasing and the cost of retaining compatibility with older versions > of the Glucose API is reasonable for at least a few releases.) Oh, no! Let's not go down this way. Pretty please? It took 10 years for the Linux distros to mature their packaging infrastructure to the point it became really usable by end-users. This includes all the tools for building binaries, dependency solving, repository management, build clusters, QA and, finally, good UIs. Now that the path is clear, it might take only 5 years of development to start over from the XO bundles. I'm unable to estimate how many full-time developers it would take, though. OR, we could pick the native distro packaging systems off the shell and make the necessary changes to make them work slightly differently as needed. > So clearly teachers/schools aren't Sugar Labs' target for its' > deliverables because their desire for stability is incompatible with > the fast changing, (almost) never look back release model of Sugar and > Fedora. I'm glad that we cleared that up :-( The word "stability" in software is mostly a marketing term with no technical substance. It also means wildly different things depending on the user you ask to. Some users would call stable an old version of Windows 98 that blue screens all the time, because it has just the bugs they're familiar with, and none of those they're not yet used to. I have been running CentOS and RHEL on some servers, and they were a complete PITA. For example, my usual backup scripts were hitting an rsync bug that was fixed years ago. Oh, and I had to manually install the web applications I actually needed from source... because the versions bundled with the "stable" distros were amazingly old. But if you resort to manual installations, don't you also loose all the advertised stability and the benefits of long-term support? Modern distros with 6 months release cycles are getting better at QA. Even Fedora is no longer the bleeding razor blade that it used to be. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Long-term support for Sugar
Yes, a PackageKit backend that handles .xo files could be written. I believe I've suggested this before. --Scott On Tuesday, September 22, 2009, Peter Robinson wrote: > On Tue, Sep 22, 2009 at 1:40 PM, Tomeu Vizoso wrote: >> On Tue, Sep 22, 2009 at 00:54, Peter Robinson wrote: >>> On Mon, Sep 21, 2009 at 11:47 PM, Martin Dengler >>> wrote: On Mon, Sep 21, 2009 at 05:15:31PM -0500, Yamandu Ploskonka wrote: > Chris Ball wrote: > > Hi, > > > > > TBH I'm not 100% sure on that as I'm not a PackageKit developer > > > but I believe that is addressed by ConsoleKit and as its in use > > > on Fedora and I'm pretty sure Ubuntu and others (and I'm pretty > > > sure its an external dependency of gnome too) I'm sure that issue > > > has been addressed. > > > > My understanding is that the developers consider it addressed by > > "%post runs as root, and if you don't like it then don't install RPMs > > [from untrusted sources]". So, we need to find out what's up there. > > > > - Chris. > > Very good point you make. It gets complicated as the users - kids - > have not been shown they get it regarding giving their full name, age > and address and some even phone number, so it is unlikely they will deal > safely with the nuances of "untrusted sources". > It would be sort of a shame that the first massive attack of malware on > Linux platforms happened under our watch... The whole point of Rainbow is that what I think you're talking about isn't an issue, and it's encouraged that kids share Activities. Eliminating this sharing ability is one of the problems with the current rpm / PackageKit proposals AIUI. >>> >>> How is the sharing implemented currently? I don't see how its >>> different to say installing an activity via the control panel as I >>> don't believe it leaves the .xo lying about for easy sharing. >> >> Yes, the control panel puts the .xo in the journal, from where it gets >> installed. > > Excellent so exactly the same could be done if package kit was used. > > Peter > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- ( http://cscott.net/ ) ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Long-term support for Sugar (was: slobs... blah blah)
[cc += mstone] [cc -= everyone else] El Mon, 21-09-2009 a las 12:54 -0400, Bill Bogstad escribió: > I agree with your statement about security updates being what is > desired here However, you can have bugs elsewhere > in the stack which can cause problems even if all anyone ever runs > directly are Sugar activities: > > 1. Single packet DOS attacks against the kernel. Yes, but the vast majority of these actually affect weird network protocols that nobody's using (such as IPX or AFP) or weird IP options that are not normally exploitable with a regular Internet client. > 2. Overflow bugs in the DNS resolver libraries of the system which are > triggered by simply doing a DNS query from the browser. (Implies no > bug in the browser itself.) Yes, those were really scary... the DNS code is as ugly and unsafe as all ancient BSD code is. > 3. Overflow bugs in ANY non-Sugar library/program which is used by an > Activity and whose parameters come from data > which might be obtained from the Internet. Perhaps gnome libraries? > Python interpreter/core libraries? I believe Read is a wrapper for > evince and/or poppler, Speak is a wrapper for espeak or gst-espeak. > Any activity which wraps a standard Linux program is a potential > problem. Indeed. This is one more reason why I dislike the notion of drawing a straight line in across a modern distribution and call everything on one side "system" and everything on the other side "applications". We have very advanced package systems in Linux, we don't need to regress to Windows-era tools that can't upgrade the system and its applications consistently. If it were on me, I'd kill the XO bundle format and find a different way to enable unprivileged installation of activities Presently, giving out root to activities would not even constitute an actual regression in security, since we do not have a fully functional version of Rainbow anyway. But I agree we should fix this weakness one day. > Sure an activity can attempt to filter out bad data. I see this as > getting into the anti-virus signature game though. Every time an > activity is modified to filter out some new variant the attacker will > just change their data slightly by adding padding, etc. Maybe it > wouldn't be as bad as I suggest, but it could get ugly fast and > activity performance would suffer as data was parsed in two places > (wrapper and core program). We are not yet a target because most > Sugar installations (XO-1s) are slow and at the end of really slow > network pipes. Always-on Sugar workstations in developed world > schools sound like a much better target. Not as nice as ubiquitous > Windows boxes, but still of interest. I think partitioning security using native UNIX concepts (uids and permissions) can be done effectively with a negligible performance hit. It's technically feasible, and Michael Stone has a 90% finished implementation of this concept. Now all we need to do is the *other* 90% of the work to make it ready for production :-) > Even RedHat's $30 pricing for desktop support for educational users is > higher then I believe SoaS (or its equivalent) needs to support. > Tomeu's CentOS suggestion is more plausible to me. I wasn't suggesting paying Red Hat to support us. I was suggesting that some companies -- like, for example, Solution Grove -- could offer such long-term support service to schools for a fee. Such companies could decide to create a CentOS based spin of SoaS, or backport the security fixes themselves, or maybe even ensure that major OS upgrades are synchronized with the beginning of the school year and work seamlessly for the all the hardware they support. It's really up to them to figure out what makes their own customers happy. Sugar Labs does not need to spend a single buck on this, exactly the same way the Kernel Hackers don't need to care about linux-2.6.18 today... unless they're employed at Red Hat, of course! ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Long-term support for Sugar (was: slobs... blah blah)
On Mon, Sep 21, 2009 at 3:25 PM, Bernie Innocenti wrote: > [cc += mstone] > [cc -= everyone else] > > El Mon, 21-09-2009 a las 12:54 -0400, Bill Bogstad escribió: >> I agree with your statement about security updates being what is >> desired here However, you can have bugs elsewhere >> in the stack which can cause problems even if all anyone ever runs >> directly are Sugar activities: >> >> 1. Single packet DOS attacks against the kernel. > > Yes, but the vast majority of these actually affect weird network > protocols that nobody's using (such as IPX or AFP) or weird IP options > that are not normally exploitable with a regular Internet client. If the attacker social engineers you into visiting their web site/network resource, I believe that they can request any IP option they like during the initial handshake. Stateless packets (ICMP or UDP) can also be directed your way at any time. >>3.[general problems with software boundary issues/program/library wrappers] > Indeed. This is one more reason why I dislike the notion of drawing a > straight line in across a modern distribution and call everything on one > side "system" and everything on the other side "applications". > > We have very advanced package systems in Linux, we don't need to regress > to Windows-era tools that can't upgrade the system and its applications > consistently. The lack of good dependency reporting and version tracking for Activities makes this difficult. Something like XO bundles could work better for for some scenarios though. For example, has anyone ever done anything with the 'host_version' field in the Activities *.info file? Maybe it could be hijacked for Sugar library dependencies. Not as remotely capable as full dependency checking, but core Sugar (glucose) could at least use this for direct Activity dependency issues. Preferentially with a pop-up telling people there may be incompatibilities. Activities that stick with direct Sugar supplied functionality would be safe. Glucose would know what range of values it supports and would alert if an Activity is outside of that range. Activities would request the minimum value that works for them in their info file. Perhaps Activities could also query for the maximum value supported and change their behavior based on it. (This assumes that Glucose functionality is monotonically increasing and the cost of retaining compatibility with older versions of the Glucose API is reasonable for at least a few releases.) > I wasn't suggesting paying Red Hat to support us. I was suggesting that > some companies -- like, for example, Solution Grove -- could offer such > long-term support service to schools for a fee. > > Such companies could decide to create a CentOS based spin of SoaS, or > backport the security fixes themselves, or maybe even ensure that major > OS upgrades are synchronized with the beginning of the school year and > work seamlessly for the all the hardware they support. > > It's really up to them to figure out what makes their own customers > happy. Sugar Labs does not need to spend a single buck on this, exactly > the same way the Kernel Hackers don't need to care about linux-2.6.18 > today... unless they're employed at Red Hat, of course! ;-) So clearly teachers/schools aren't Sugar Labs' target for its' deliverables because their desire for stability is incompatible with the fast changing, (almost) never look back release model of Sugar and Fedora. I'm glad that we cleared that up :-( Bill Bogstad ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
