>At 10.23 +0000 2000.03.22, Matt Sergeant wrote: >>> # More work on a safe and secure execution environment >>> # for mobile agents >>> >>> Is Safe not enough? What's left? What about safeperl? >> >>Safe simply doesn't work in its current state. >It does, but not in all cases. The only problems I saw with Safe in the >exchange with you and Tom is with other packages and requiring and >importing and such. This is something that needs to be fixed eventually, >but I don't want statements like that above to drive people away from using >Safe to do operations that do work. Um, no. There are fundamantal flaws. It's more than just getting require to work. The package name is not correctly stored, which means things can sneak out across method calls. Think about it: nothing is to stop a Safe compartment whose package name is Foo from blessing to class FileHandle, which is stored as "FileHandle", not as "Foo::FileHandle" or "::Foo::FileHandle" or such. When you call a method on that object, you'll get the wrong class. This is very wrong. More importantly, all of Perl's global state is hanging out there. Why should setting $\ in one compartment hurt the rest of them? How about $*? These just go on and on. The right solution at this stage really seems an ithreads-based interpreter-per-compartment system. Again, though, we don't exactly know how to do sharing between them yet. --tom