That's why if there's any doubt, I'd recommend to not eval at all.

Correct. And that also excludes do FILE, require, and use. See Re^4: Using guards for script execution? for details.

The sane way of handling foreign data is to use a non-executable format like JSON. Perl has several JSON parsers / generators at CPAN.

YAML can contain executable code (but I think you have to explicitly enable that). XML does not contain executable code, but it may contain references to local and network resources (https://en.wikipedia.org/wiki/XML_external_entity_attack) and it may contain DoS attacks (https://en.wikipedia.org/wiki/Billion_laughs). YAML is also vulnerable to the latter attack. CSV and INI file formats may appear simple, but both are essentially underspecified and thus have some "interesting" edge cases. Text::CSV_XS can handle most, if not all CSV files, because it has support for most, if not all of the edge cases.

Of course, it would be possible to define a very restricted subset of Perl for data exchange, like JSON is a very restricted subset of Javascript. But it seems nobody has done that yet. A basic requriement would be to forbit any executable code; and I think that cyclic references should also be avoided. The format may look very similar to the output of Data::Dumper, but without any variable names. Parsing that subset should be quite easy, as it would pretty much look like JSON.

Alexander