KernelImage plans, namespaces, security, ???

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

KernelImage plans, namespaces, security, ???

Michael van der Gulik-2
Hi all, especially Pavel.

What are your long-term plans for KernelImage?

I'm working on a more secure version of squeak, and KernelImage looks like a good starting point.

Pavel: would you want the following features in KernelImage, most of which would break backwards compatibility:

- Hierarchical Namespaces,

- Preventing multiple applications in an image from being able to affect each other (in terms of excessive memory usage etc),

- Capability-based security, meaning that core Squeak classes cannot be modified, devices must be granted access to, etc, enabling you to load foreign, untrusted code and execute it securely.

If so, then I'd like to work with you on this. If not, I'll have to fork KernelImage for my own project.

I assume you've released KernelImage under the MIT license?

Cheers,
Michael.


Reply | Threaded
Open this post in threaded view
|

RE: KernelImage plans, namespaces, security, ???

J J-6
You want the Kernel image to do these things you listed, or just have them
as an option?


>From: "Michael van der Gulik" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: KernelImage plans, namespaces, security, ???
>Date: Thu, 15 Mar 2007 11:33:51 +1300
>
>Hi all, especially Pavel.
>
>What are your long-term plans for KernelImage?
>
>I'm working on a more secure version of squeak, and KernelImage looks like
>a
>good starting point.
>
>Pavel: would you want the following features in KernelImage, most of which
>would break backwards compatibility:
>
>- Hierarchical Namespaces,
>
>- Preventing multiple applications in an image from being able to affect
>each other (in terms of excessive memory usage etc),
>
>- Capability-based security, meaning that core Squeak classes cannot be
>modified, devices must be granted access to, etc, enabling you to load
>foreign, untrusted code and execute it securely.
>
>If so, then I'd like to work with you on this. If not, I'll have to fork
>KernelImage for my own project.
>
>I assume you've released KernelImage under the MIT license?
>
>Cheers,
>Michael.


>

_________________________________________________________________
Find a local pizza place, movie theater, and more….then map the best route!
http://maps.live.com/?icid=hmtag1&FORM=MGAC01


Reply | Threaded
Open this post in threaded view
|

Re: KernelImage plans, namespaces, security, ???

Michael van der Gulik
They're all major architectural changes so they wouldn't be an option.

Personally I think a fork would be best, but I'd like to hear what
Pavel's plans or intentions are for KernelImage.

Michael.

J J wrote:

> You want the Kernel image to do these things you listed, or just have
> them as an option?
>
>
>> From: "Michael van der Gulik" <[hidden email]>
>> Reply-To: The general-purpose Squeak developers
>> list<[hidden email]>
>> To: "The general-purpose Squeak developers
>> list"<[hidden email]>
>> Subject: KernelImage plans, namespaces, security, ???
>> Date: Thu, 15 Mar 2007 11:33:51 +1300
>>
>> Hi all, especially Pavel.
>>
>> What are your long-term plans for KernelImage?
>>
>> I'm working on a more secure version of squeak, and KernelImage looks
>> like a
>> good starting point.
>>
>> Pavel: would you want the following features in KernelImage, most of
>> which
>> would break backwards compatibility:
>>
>> - Hierarchical Namespaces,
>>
>> - Preventing multiple applications in an image from being able to affect
>> each other (in terms of excessive memory usage etc),
>>
>> - Capability-based security, meaning that core Squeak classes cannot be
>> modified, devices must be granted access to, etc, enabling you to load
>> foreign, untrusted code and execute it securely.
>>
>> If so, then I'd like to work with you on this. If not, I'll have to fork
>> KernelImage for my own project.
>>
>> I assume you've released KernelImage under the MIT license?
>>
>> Cheers,
>> Michael.
>
>
>
>>
>
> _________________________________________________________________
> Find a local pizza place, movie theater, and more….then map the best
> route! http://maps.live.com/?icid=hmtag1&FORM=MGAC01
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: KernelImage plans, namespaces, security, ???

J J-6
Well my understanding was Pavel's work was going to be the basis for future
Squeak images to build on, so personally I would be for forking.


>From: Michael van der Gulik <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: The general-purpose Squeak developers
>list<[hidden email]>
>Subject: Re: KernelImage plans, namespaces, security, ???
>Date: Thu, 15 Mar 2007 22:46:45 +1300
>
>They're all major architectural changes so they wouldn't be an option.
>
>Personally I think a fork would be best, but I'd like to hear what Pavel's
>plans or intentions are for KernelImage.
>
>Michael.
>
>J J wrote:
>>You want the Kernel image to do these things you listed, or just have them
>>as an option?
>>
>>
>>>From: "Michael van der Gulik" <[hidden email]>
>>>Reply-To: The general-purpose Squeak developers
>>>list<[hidden email]>
>>>To: "The general-purpose Squeak developers
>>>list"<[hidden email]>
>>>Subject: KernelImage plans, namespaces, security, ???
>>>Date: Thu, 15 Mar 2007 11:33:51 +1300
>>>
>>>Hi all, especially Pavel.
>>>
>>>What are your long-term plans for KernelImage?
>>>
>>>I'm working on a more secure version of squeak, and KernelImage looks
>>>like a
>>>good starting point.
>>>
>>>Pavel: would you want the following features in KernelImage, most of
>>>which
>>>would break backwards compatibility:
>>>
>>>- Hierarchical Namespaces,
>>>
>>>- Preventing multiple applications in an image from being able to affect
>>>each other (in terms of excessive memory usage etc),
>>>
>>>- Capability-based security, meaning that core Squeak classes cannot be
>>>modified, devices must be granted access to, etc, enabling you to load
>>>foreign, untrusted code and execute it securely.
>>>
>>>If so, then I'd like to work with you on this. If not, I'll have to fork
>>>KernelImage for my own project.
>>>
>>>I assume you've released KernelImage under the MIT license?
>>>
>>>Cheers,
>>>Michael.
>>
>>
>>
>>>
>>
>>_________________________________________________________________
>>Find a local pizza place, movie theater, and more….then map the best
>>route! http://maps.live.com/?icid=hmtag1&FORM=MGAC01
>>
>>
>>
>
>

_________________________________________________________________
Mortgage rates as low as 4.625% - Refinance $150,000 loan for $579 a month.
Intro*Terms  
https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f6&disc=y&vers=743&s=4056&p=5117


Reply | Threaded
Open this post in threaded view
|

Re: KernelImage plans, namespaces, security, ???

Pavel Krivanek
In reply to this post by Michael van der Gulik-2
Hi Michael,

On 3/14/07, Michael van der Gulik <[hidden email]> wrote:

> Hi all, especially Pavel.
>
> What are your long-term plans for KernelImage?
>
> I'm working on a more secure version of squeak, and KernelImage looks like a
> good starting point.
>
> Pavel: would you want the following features in KernelImage, most of which
> would break backwards compatibility:
>
> - Hierarchical Namespaces,
>
> - Preventing multiple applications in an image from being able to affect
> each other (in terms of excessive memory usage etc),
>
> - Capability-based security, meaning that core Squeak classes cannot be
> modified, devices must be granted access to, etc, enabling you to load
> foreign, untrusted code and execute it securely.
>
> If so, then I'd like to work with you on this. If not, I'll have to fork
> KernelImage for my own project.

The KernelImage is not designed as a fork of Squeak. Contrariwise it
should help to share code between current Squeak forks. So if the
Squeak community will want and accept this changes then it will be
part of the KernelImage. Current KernelImage itself is only an
evolutional step to better Squeak modularization (~Spoon).

So if you really want this, you will have to fork - it would be nice
if it will be possible to have it as the optional functionality. Then
it will be easier to accept it in general.

> I assume you've released KernelImage under the MIT license?

My changes are under MIT license but the original code is still under Squeak-L.

Cheers,
-- Pavel


> Cheers,
> Michael.
>