[IAEP] [Sugar-devel] [SLOBS] SoaS: Searching for Decision Panel volunteers.
bogstad at pobox.com
Mon Sep 21 12:54:41 EDT 2009
On Mon, Sep 21, 2009 at 10:41 AM, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Mon, 21-09-2009 a las 10:14 +0200, Tomeu Vizoso escribió:
>> Yes, the most obvious path is to be based on the next CentOS major
>> release, which in turn will be based on Fedora 11 (AFAIK).
>> Switching to other distros with LTS is of course possible but then it
>> will be most probably carried out by a different team than SoaS
> The only reason you want a distribution to be long-term supported is
> security updates, but those tend to affect mostly server applications
> (which we don't have) or multiuser environments (and we have only one
> user). The only remaining pieces that may contain vulnerabilities are
> the Activities. Especially the web browser.
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.
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.)
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
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.
> This creates a sustainable market for Sugar. Linux distributors who
> have successfully built a reputation for offering good customer support,
> such as Red Hat, *do* make good profits and *do* reinvest a large part
> of them to contribute back to Linux development. Everyone wins.
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.
More information about the IAEP