Re^4: trouble with packages/eval/variable-scoping

First of all I can't see that it's a config file.

Secondly, the same must apply to all modules etc.

Thirdly, if the OP is generating code in his Tk app and keeps it safe, where is the problem?

This would apply as meta programming, and I could come up with multiple use cases for this.

Meta

I really have a problem with dogmatic preaching just after a trigger point like eval is shown ...

I'm pretty sure we wouldn't have seen this discussion if the OP was using require to load the code.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

see Wikisyntax for the Monastery}

Comment on Re^4: trouble with packages/eval/variable-scoping

Replies are listed 'Best First'.
Re^5: trouble with packages/eval/variable-scoping by hippo (Archbishop) on Aug 30, 2024 at 13:12 UTC
Thirdly, if the OP is generating code in his Tk app and keeps it safe, where is the problem? Then there would be no great problem. However, keeping it safe is not trivial and that's why we have all kinds of helpful protections to ward off such things. There is nothing at all to stop any Perl programmer (or TBH, any programmer of whatever flavour) from shooting themselves in the foot. If a programmer is happy with the potential consequences then they are perfectly free to be as laissez-faire as they wish. I just wouldn't want anyone to be going down that road without being aware of those potential consequences. YMMV. 🦛	[reply]
Re^6: trouble with packages/eval/variable-scoping by LanX (Saint) on Aug 30, 2024 at 13:41 UTC
> keeping it safe is not trivial If a program is saved in a user's directory and only accessible with his credentials I wonder what kind of vector you see that is not already open for other apps? Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply]
Re^7: trouble with packages/eval/variable-scoping by hippo (Archbishop) on Aug 30, 2024 at 13:58 UTC
It is dynamic code being generated on the fly and so is susceptible to either malignancy or accident even before being saved. And being saved, apparently without locking, it is also potentially subject to corruption at that point too. There are surely other avenues which don't immediately spring to mind as well. Defensive programming when running dynamic code from a tainted (in the sense of taint mode) source is very difficult and how much time and effort you want to spend statically analysing it before running or cryptographically verifying or whatever is going to depend on the value of the system and the cost of it all going horribly wrong. It boils down to three basic scenarios: The effort is worth it, so you put in the hard work to secure it AFAP. The effort is not worth it but the risk is acceptable, so you live with it and just keep your fingers crossed. The effort is not worth it and the risk is unacceptable so you just don't run the untrusted code and find some other way instead. 🦛	[reply]