in reply to Intercepting compile time blocks like BEGIN {}

automated testing if code can be safely syntax checked without executing code

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

Also, it would prevent syntax checking a module as that requires executing require.

EPIC uses PPI to parse the script without executing anything. It does a great job of finding errors reliably.

Anyway, I don't see the problem. If you've installed the module, you've already accepted its evilness. I don't see what good a syntax check of an untrusted module would do. Just like you wouldn't execute it, don't do a syntax check on it.

Replies are listed 'Best First'.
Re^2: Intercepting compile time blocks like BEGIN {}
by LanX (Saint) on Aug 09, 2010 at 21:24 UTC
    > 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

      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.

        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.