Re^2: Vulnerabilities when editing untrusted code...

Every perl editor which tries to check for compile time errors and warnings (Komodo, Padre, emacs with flyspell using perl -c, vi?) need to put use Safe upfront, and no Safe at the end of the BEGIN or the begin of INIT.

This cannot be done within Perl generally as users need to execute BEGIN blocks, just not in editors.

The only remaining problem with Safe is then XS code, which might get executed at compile-time and cannot be checked for harm.

Comment on Re^2: Vulnerabilities when editing untrusted code...

Replies are listed 'Best First'.
Re^3: Vulnerabilities when editing untrusted code... by BrowserUk (Patriarch) on Aug 09, 2010 at 14:42 UTC
Every perl editor which tries to check for compile time errors and warnings... Which is one reason I don't use such editors. It's like sticking your finger in a power socket to check if it's live. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply]
Re^4: Vulnerabilities when editing untrusted code... by Anonymous Monk on Aug 09, 2010 at 14:53 UTC
It's like sticking your finger in a power socket to check if it's live. Or to see if there are any wires in it, bad idea all around (ouch)	[reply]
Re^3: Vulnerabilities when editing untrusted code... by LanX (Saint) on Aug 09, 2010 at 21:07 UTC
Hi Reini I'm not sure what you mean... the editor should parse the code for all occurrences of BEGIN, CHECK and UNITCKECK and wrap each block with "use Safe" and "no Safe"? Regarding the described problems to parse for such blocks I have no idea how to achieve this reliably withot adding a hook to Perl's parser. Please see Intercepting compile time blocks like BEGIN {} for more detailed description of what I mean. Cheers Rolf	[reply]