[ic] Safe.pm (was Re: [interchange-core] Encoding of mail headers)

[Mike Heins]

Quoting David Christensen (david at endpoint.com):
> However, Safe also falls down with anything that isn't explicitly  
> imported and evaluated in a single package (think any OO-style  
> software).

It manages to work pretty nicely with DBI, which is object-oriented. 

>  AIUI, this is why there are the various aliasing into the  
> compartment for $Scratch, $Tags, etc, as you can't access $Vend::Tags,  
> etc.  This is a known limitation of Safe, and is what we're ultimately  
> running up against, require issues aside.  Even if we were to untrap  
> *all* operations, I don't think you can access other packages from the  
> compartment, and AFAIK this is not a restriction that can be lifted  
> while still using Safe.
> 
> I understand the reasons for using Safe originally, and for quick  
> snippets and smaller blocks of code it works fine, but for anything  
> which needs to access other packages than the current, it fails  
> miserably.  What are the ultimate protections that Safe was intended  
> to provide, and what would be the impact if we were to throw out the  
> Safe containers?

The impact is that users editing pages becomes as risky and problematic
as PHP is. Even more so, because of the increased ways to shell out.
Interchange has remained as stable and as relatively problem-
free as it is partly because you can't open files and do things which
are big security risks.

If you remove Safe, all of a sudden you have to try to provide
interfaces for users to edit pages, in all situations, or just
accept the risk of code that allows opening files. 

When all that happens, I fork a new version and other people
can deal with the Interchange it will become.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.328.4479  <mike at perusion.com>

I have a cop friend who thinks he ought be able to give a new ticket;
"too dumb for conditions".