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 <j...@lariat.co> 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 <ru...@mrbrklyn.com> 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 <hgibb...@gmail.com> 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 < >> di...@webweaving.org <mailto:di...@webweaving.org>> wrote: >> > > >> > > > On 30 May 2017, at 16:58, p...@cpan.org <mailto:p...@cpan.org> >> 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 >> > > hgibb...@gmail.com <mailto:hgibb...@gmail.com> >> > > 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:* > *j...@lariat.co <j...@lariat.co>* > > *Customer Service:* > 877.268.6667 > supp...@lariat.co > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co