Re: capture exception

More(and perhaps more confusing) examples:
# SECURITY RISK
eval qq{
    my $data = get_data_from_internet();
};
if ($@) {
    # TODO: Handle errors
}

# SECURITY RISK
eval q{
    my $data = get_data_from_internet();
};
if ($@) {
    # TODO: Handle errors
}

# NOT A SECURITY RISK
eval {
    my $data = get_data_from_internet();
};
if ($@) {
    # TODO: Handle errors
}

On Tue, May 30, 2017 at 1:59 PM, John Dunlap <[email protected]> wrote:

> With all due respect, Ruben, unless I'm totally missing something(which is
> totally possible), you're being a little alarmist. According to perldoc you
> can call eval with two different ways:
>
>    - *eval EXPR*
>    - *eval BLOCK*
>
> The first approach is inherently a security risk, as you have correctly
> pointed out, but the second is not inherently a security risk and, to the
> best of my knowledge, is the only way of catching unhandled runtime errors.
> For example,
>
> # SECURITY RISK
> my $data = get_data_from_internet();
> eval $data;
>
> # NOT A SECURITY RISK
> eval {
>     my $data = get_data_from_internet();
> };
> if ($@) {
>     # TODO: Handle errors
> }
>
> On Tue, May 30, 2017 at 1:47 PM, Ruben Safir <[email protected]> wrote:
>
>> On Tue, May 30, 2017 at 05:10:17PM +0100, Clive Eisen wrote:
>> > It is only a security hole if you eval user input.
>> >
>>
>>
>> What do you call return values from the internet?
>>
>> >
>> > --
>> > Clive Eisen
>> > GPG: 75056DD0
>> >
>> >
>> >
>> >
>> >
>> >
>> > > On 30 May 2017, at 17:00, Hiram Gibbard <[email protected]> wrote:
>> > >
>> > > I might be hijacking this... Sorry, but...I recently used the Perl
>> eval function to determine if a ldap search returned a error or not.
>> Basically, a user's record has a attribute that points to a assistant, and
>> If that assistant no longer exists the app was throwing a error since it
>> executed a ldap call to that assistant's record. So I used eval to check if
>> the error was returned, and if so, skipped the function where it tied
>> searched the assistant record in ldap.  Is this the same eval scenario you
>> described which has a security whole?
>> > >
>> > >
>> > > I was just reading everyone's reply and now I am worried I created a
>> security hole.
>> > >
>> > > Thanks
>> > >
>> > > On Tue, May 30, 2017 at 10:04 AM, Dirk-Willem van Gulik <
>> [email protected] <mailto:[email protected]>> wrote:
>> > >
>> > > > On 30 May 2017, at 16:58, [email protected] <mailto:[email protected]>
>> wrote:
>> > > >
>> > > > On Tuesday 30 May 2017 15:53:13 James Smith wrote:
>> > > >> String eval should be avoided at all costs [especially if you
>> parse user
>> > > >> input] - functional eval is different - and is a good model for
>> catching
>> > > >> errors etc
>> > > >
>> > > > Yes, string eval should be avoided in all usage. But this
>> discussion was
>> > > > about that functional eval.
>> > >
>> > > Aye - right you are - apologies for causing confusing and missing the
>> (/{.
>> > >
>> > > Dw.
>> > >
>> > >
>> > >
>> > > --
>> > > Hiram Gibbard
>> > > [email protected] <mailto:[email protected]>
>> > > http://hiramgibbard.com <http://hiramgibbard.com/>
>> > >
>> >
>>
>> --
>> So many immigrant groups have swept through our town
>> that Brooklyn, like Atlantis, reaches mythological
>> proportions in the mind of the world - RI Safir 1998
>> http://www.mrbrklyn.com
>>
>> DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
>> http://www.nylxs.com - Leadership Development in Free Software
>> http://www2.mrbrklyn.com/resources - Unpublished Archive
>> http://www.coinhangout.com - coins!
>> http://www.brooklyn-living.com
>>
>> Being so tracked is for FARM ANIMALS and and extermination camps,
>> but incompatible with living as a free human being. -RI Safir 2013
>>
>>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *[email protected] <[email protected]>*
>
> *Customer Service:*
> 877.268.6667
> [email protected]
>



-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*[email protected] <[email protected]>*

*Customer Service:*
877.268.6667
[email protected]