[Sugar-devel] [SLOBS] Long-term support for Sugar (was: slobs... blah blah)

[Peter Robinson]

On Mon, Sep 21, 2009 at 8:45 PM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Mon, Sep 21, 2009 at 19:25, Bernie Innocenti <bernie at codewiz.org> 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.
>>
>>
>>> 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! ;-)
>
> Well, if we decide that future releases of Sugar should run ok on the
> next major release of CentOS, we cannot depend on later versions of
> python, gtk, etc.

I'm not sure something like sugar which is (and should be) fast moving
mixes well with something like CentOS or its parent. At the beginning
of the v6 release cycle begins it will be fine but within 12 months
I'm sure everyone will want the features that are provided by the
latest release of gtk/glib/gstreamer/python/telepathy etc that just
won't be available in v6 so we en up in a situation we've been in
before where we either need to fork massive amounts of packages to get
the features everyone wants or moving back to Fedora. Both which will
require lots of work. I know what its like as I've spent lots and lots
of hours getting the changes merged upstream.

Peter