On the bigger question of open source and security, Open and Closed Systems are Equivalent seems to be a good approximation of reality. While open source software is likely to be of better quality than closed source, it is also easier to analyze for security holes. Those two effects seem to offset each other pretty well, with a wide variance by project.

For more background, Economics and Security has a lot of interesting material on why people wind up accepting insecurity.

My understanding is that Safe is not very safe. And it is restrictive enough to keep virtually any interesting code from running. Therefore I would not recommend running it.

Ya know, I've heard a lot of people repeat this, but I have yet to see any actual demonstration of breaking a Safe container. Not that I'm saying it can't be done, merely that I've yet to see people prove their repeated statements of "oh it's not very safe". I'm also not trying to single you out specifically, obviously, you just happened to have repeated it most recently.

So, does *anyone* have any evidence that the current Safe "isn't very safe"?

So, does *anyone* have any evidence that the current Safe "isn't very safe"?

Yup. The continual number of exploits and fixes made in the library. Even if there are no currently known exploits the history of the module makes me deeply suspicious that it can be relied upon as the primary mechanism for securing code.

Looking at the text you are referring to, the perl section mentions taint mode, which in my humble opinion is much more useful and important than safe containers. I've never had need to use a safe container - I'm also quite sparing with eval string.

Would you use it for filesystem things etc.?

I would use taint mode and untainting through a regex for these kind of operations. See Ovid's CGI course for a discussion of the security implications and an explanation of how to do this.

In terms of whether you should publish your source - this depends on your level of paranoia, and the fact that the white hats tend to out number the black hats, so you are more likely to get feedback about security holes before your application gets compromised. But, beware also the advice given in this thread.

I would think that while the author of Safe considers it unsafe (sounds weird really:-) it may be better then not using it at all.

I'm not so sure. The promise of Safe.pm was that it would provide safe compartments for code to be evaluated in. The history of Safe.pm means that I'm very skeptical that this is true.

So if somebody uses Safe.pm and thinks "fantastic - all my security problems with remote code are solved" then I think they're probably going to be surprised at some point. A better solution would be a design that avoids running potentially insecure code at all.