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
