in reply to Re^2: unable to eval dumped hash
in thread unable to eval dumped hash

There is also the Safe module for evaluating untrusted input while limiting possible damage.

That way requires a LOT of trust in the safety of Safe. One error in Safe or simply in the actual configuration of Safe and you are in BIG trouble.

The safe way of saving and restoring data is to handle it as data, not as code. See also Re: Accessing variables in an external hash without eval, Re^4: Accessing the hash name in perl, Re^2: DBI fetchall_hashref convert to scalar, Re^2: DBI fetchall_hashref convert to scalar, Re: What's the right way to include a config file as a .pm bareword?.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^4: unable to eval dumped hash
by jcb (Parson) on Apr 30, 2020 at 01:28 UTC
    That way requires a LOT of trust in the safety of Safe.

    Perhaps so, but I do not expect that trust to be misplaced. Tcl uses the same concept for its "safe" interpreters and I do not recall any exploits in either that Tcl facility or Perl's Safe. Do you have a counterexample?

    The safe way of saving and restoring data is to handle it as data, not as code.

    I agree that that is the preferred option, but interface constraints from existing systems can interfere.

[reply]
      Perhaps so, but I do not expect that trust to be misplaced.

      The issue is that Safe is opcode-specific, so it requires knowledge of the Perl internals: what code is compiled to which opcodes, which opcodes should I allow, what does each allowed opcode do, and how have those opcodes changed across Perl versions.

      Update: See also the thread More strongly discourage Safe.pm? on P5P.

[reply]

In Section Seekers of Perl Wisdom