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

[Bill Bogstad]

On Mon, Sep 21, 2009 at 3:25 PM, 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.

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