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
In reply to Re^4: Accessing the hash name in perl
by afoken
in thread Accessing the hash name in perl
by Sonali
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |