Have you got links/examples?

Many :-)

A quick look at the perl bug site will give you several, including:

• Safe reval bleeds local variable values
• Security-Hole in module Safe.pm
• Sharing leak root name into safe compartment

A quick grep through Perl's change files will supply many other instances. For example from Changes5.8.1:

The CHECKOP macro was not invoked on some newly created ops (to match them against the current opmask.) As a consequence, Safe compartments were unable to trap some ops (pattern match, slices, conditionals.) This fixes the holes.

So, unless you are running 5.8.2 which has out for less than a week, there are already known exploits in Safe.pm, and goodness knows how many unknown ones.

(update: of course, Changes5.8.1 refers to the changes made in 5.8.1 - so it's not quite as bad as I originally said. still not good tho')

This is why I would not rely on Safe.pm for security.

As a tool to help track down issues it's great - it catches a lot of stuff. However, as the sole line of defence it's history is just too full of security holes for me to have any great faith in it.

Instead, use alternate tactics:

• If you need to dump data structures avoid situations where you have to compile arbitrary code (e.g. Use YAML instead of Data::Dumper.)
• If you need to run code define a "safe" domain specific language and use that (e.g. Template).
• Authenticate safe code from known sources using public/private keys.
• etc.

A quick look at the perl bug site will give you several, including:

Safe reval bleeds local variable values

To be fair, I think that problem was both introduced and fixed between 5.8.0 and 5.8.1 and was never a problem in a released version (from memory).

True, but I don't think it alters my main point ;-) Safe has a history of being buggy. To use it as your only line of defense at this stage is probably a mistake (IMHO).