Re: E patches for review: ELoader, FileGetter

On 24 May 2010 20:14, Kevin Reid <kpreid-M/[email protected]> wrote:
> On May 24, 2010, at 14:14, Thomas Leonard wrote:
>
>> What are the security implications? e.g. say I have a file like this:
>>
>> # securePair.emaker
>> interface FooGuard guards FooAuditor { }
>> [FooGuard,FooAuditor]
>>
>> Before, another emaker could import this and use FooAuditor. If anyone
>> else imported it, they just got a new copy and no harm done. Now, that
>> same code would be insecure.
>>
>> I don't think I've seen any code like this, but maybe there are more
>> subtle cases?
>
> It has always been the expectation that <import:foo> is not a
> significant authority by itself whereas <import:foo>() (when foo =
> makeBar) is. As far as I know, there is no emaker in any E
> implementation or application which relies on the fact that they are
> multiply instantiated.
>
> The multiple instantiation is simply a mechanism to ensure that
> <import> does not become a communication channel between separate
> confined components that works despite our lack of DeepFrozen auditing.

OK.

Is Traceln DeepFrozen?

If not, how do you debug DeepFrozen objects? If so, what prevents the
compiler optimising it out?


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA