in reply to Re: Intercepting compile time blocks like BEGIN {}
in thread Intercepting compile time blocks like BEGIN {}

> Actually, disabling BEGIN blocks would greatly reduce the value of s syntax check. For example, it would

> ...

I'm aware of this, but thats exactly why I was describing a call-back function to control the process.

For instance the filepath could be taken to make a distinction between trusted and new code.

And rurban's suggestion to wrap the code into a Safe environment could be chosen to allow execution of BEGIN blocks in untrusted code.

> EPIC uses PPI to parse the script without executing anything.

Tell me, PPI can find BEGIN-Blocks like in ''=~('(?{B'.'EGIN{print "owned"}})') ?

AFAIK PPI can not deal with all kinds of syntax changing mechanisms. So wouldn't be of much help when searching for evil code, since attackers could use these limitations.

Cheers Rolf

  • Comment on Re^2: Intercepting compile time blocks like BEGIN {}

Replies are listed 'Best First'.
Re^3: Intercepting compile time blocks like BEGIN {}
by ikegami (Patriarch) on Aug 09, 2010 at 22:00 UTC

    For instance the filepath could be taken to make a distinction between trusted and new code.

    How does that help? Three of the four examples I gave still stand, and you still can't syntax check a module.

    And rurban's suggestion to wrap the code into a Safe environment

    Safe is considered not safe.

    Tell me, PPI can find BEGIN-Blocks like in ''=~('(?{B'.'EGIN{print "owned"}})') ?

    It shows as a regex literal, which sounds good to me.

    So wouldn't be of much help when searching for evil code, since attackers could use these limitations.

    Using PPI removes the need to detect such attacks. The only reason you need to detect the attacks is that your method is susceptible to them.

[reply]
      Using PPI removes the need to detects such attacks.

      PPI can't be used when I execute the code, if PPI doesn't reliably help me finding all BEGIN Blocks in advance it's of no helpš.

      Your concentrating on the "editor does syntax check" use case.

      Cheers Rolf

      UPDATES 1) ... when investigation foreign code.

[reply]

        Your concentrating on the "editor does syntax check" use case.

        Specifically, I focused the claim that it would allow "automated testing if code can be safely syntax checked without executing code" to show that it's false.

        The other use case you mentioned was the ability to trace the special blocks. Sure, that would be a good feature, but your suggested implementation of a command line switch makes no sense.

[reply]

In Section Seekers of Perl Wisdom