Mailing List Archive

capture exception
greeting,

I am not so good at perl/modperl,:)

In the handler, a method from a class was called, when something dies
from within the method, what's the correct way the handler will take?

for example, I wrote this API which works right if given a correct
domain name:

http://fenghe.org/domain/?d=yahoo.com

server response:
var data={"registration":"domain may be taken","domain":"yahoo.com"}

If given a wrong domain name:

http://fenghe.org/domain/?d=yahoo.nonexist

The server returns 500.

This is because, in the handler, I used this module (wrote also by me):

http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.03/lib/Net/Domain/Registration/Check.pm

And in the module, croak like this was happened,

croak "domain TLD not exists" unless tld_exists($tld);

When handler meets the croak, it dies (I guess) and server returns 500.

How will I make the full system work right? fix on handler, or the
module itself?

Thanks.
Re: capture exception [ In reply to ]
Not really a mod_perl question but you can always wrap your method call
in an eval

my $ret = eval { $m->...() };

And then check $@ for the error message


On 2017-05-26 02:08 AM, Peng Yonghua wrote:
> greeting,
>
> I am not so good at perl/modperl,:)
>
> In the handler, a method from a class was called, when something dies
> from within the method, what's the correct way the handler will take?
>
> for example, I wrote this API which works right if given a correct
> domain name:
>
> http://fenghe.org/domain/?d=yahoo.com
>
> server response:
> var data={"registration":"domain may be taken","domain":"yahoo.com"}
>
> If given a wrong domain name:
>
> http://fenghe.org/domain/?d=yahoo.nonexist
>
> The server returns 500.
>
> This is because, in the handler, I used this module (wrote also by me):
>
> http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.03/lib/Net/Domain/Registration/Check.pm
>
>
> And in the module, croak like this was happened,
>
> croak "domain TLD not exists" unless tld_exists($tld);
>
> When handler meets the croak, it dies (I guess) and server returns 500.
>
> How will I make the full system work right? fix on handler, or the
> module itself?
>
> Thanks.



--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Re: capture exception [ In reply to ]
Yes, I do that extensively and it works perfectly. It's as close to a true
Try/Catch block as we have in the perl world. However, I *usually* do not
return values from it because I use this construct to control my database
transaction demarcation and using the return value from outside of the eval
wouldn't be inside the transaction. With that said, I have had to do it
from time to time and it works just fine. Also, it is advisable to copy the
contents of $@ into a separate variable immediately. My understanding is
that this can prevent some weird concurrency issues, under some conditions.
My general form looks something like this,

my $return = eval {
# BEGIN DATABASE TRANSACTION

# DO SOME STUFF

# COMMIT DATA BASE TRANSACTION

return 'SOME VALUE';
};

if ($@) {
my $error = $@;

# ROLLBACK DATABASE TRANSACTION

# LOG ERROR
}


On Tue, May 30, 2017 at 4:47 AM, James Smith <js5@sanger.ac.uk> wrote:

> Not really a mod_perl question but you can always wrap your method call in
> an eval
>
> my $ret = eval { $m->...() };
>
> And then check $@ for the error message
>
>
> On 2017-05-26 02:08 AM, Peng Yonghua wrote:
>
>> greeting,
>>
>> I am not so good at perl/modperl,:)
>>
>> In the handler, a method from a class was called, when something dies
>> from within the method, what's the correct way the handler will take?
>>
>> for example, I wrote this API which works right if given a correct domain
>> name:
>>
>> http://fenghe.org/domain/?d=yahoo.com
>>
>> server response:
>> var data={"registration":"domain may be taken","domain":"yahoo.com"}
>>
>> If given a wrong domain name:
>>
>> http://fenghe.org/domain/?d=yahoo.nonexist
>>
>> The server returns 500.
>>
>> This is because, in the handler, I used this module (wrote also by me):
>>
>> http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.
>> 03/lib/Net/Domain/Registration/Check.pm
>>
>> And in the module, croak like this was happened,
>>
>> croak "domain TLD not exists" unless tld_exists($tld);
>>
>> When handler meets the croak, it dies (I guess) and server returns 500.
>>
>> How will I make the full system work right? fix on handler, or the module
>> itself?
>>
>> Thanks.
>>
>
>
>
> --
> The Wellcome Trust Sanger Institute is operated by Genome Research
> Limited, a charity registered in England with number 1021457 and a company
> registered in England with number 2742969, whose registered office is 215
> Euston Road, London, NW1 2BE.




--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: capture exception [ In reply to ]
Hi!

Please note that true value in $@ is *not* necessary condition for
checking if error in eval occurred. And similarly empty string or logic
false value in $@ is *not* necessary condition that eval succeeded.

The only thing which is guaranteed is undef return value from eval in
case it failed. So correct check is:

my $success = eval {
# MY CODE
1;
};

unless ($success) {
# HANDLE ERROR, $@ may (but does not have to) contain error
}

"1;" in eval block is there to set $success to 1. In case MY CODE throw
error, $success is set to undef by perl.

Note that $@ is propagated back, so you should localize $@ before
calling eval. This is especially required if MY CODE (or function called
from MY CODE) calls also eval.

So you can use this pattern:

{
local $@;
eval {
# MY CODE
1;
} or do {
# HANDLE ERROR in $@ (but may be undef!)
};
}

If you do not write 1; then return value is taken from the last call in
MY CODE. So if problem is also when last function return non zero, then
you can remove "1;". You can also combine it with "and" block, but
beware for and/or logical blocks:

{
local $@;
eval {
func_which_may_die_or_fail_with_zero();
} and do {
print "function succeeded\n";
func_may_fail_with_zero();
} or do {
my $err = $@ || 'unknown error';
warn "Error: $err\n";
rollback();
};
}

But I suggest to use module like Try::Tiny or Try::Catch which handle
above eval and $@ logic for you and you can easily write:

try {
# MY CODE
} catch {
# HANDLE ERROR in $_ (may be undef!)
my $err = $_ || 'unknown error';
};

On Tuesday 30 May 2017 09:39:53 John Dunlap wrote:
> Yes, I do that extensively and it works perfectly. It's as close to a true
> Try/Catch block as we have in the perl world. However, I *usually* do not
> return values from it because I use this construct to control my database
> transaction demarcation and using the return value from outside of the eval
> wouldn't be inside the transaction. With that said, I have had to do it
> from time to time and it works just fine. Also, it is advisable to copy the
> contents of $@ into a separate variable immediately. My understanding is
> that this can prevent some weird concurrency issues, under some conditions.
> My general form looks something like this,
>
> my $return = eval {
> # BEGIN DATABASE TRANSACTION
>
> # DO SOME STUFF
>
> # COMMIT DATA BASE TRANSACTION
>
> return 'SOME VALUE';
> };
>
> if ($@) {
> my $error = $@;
>
> # ROLLBACK DATABASE TRANSACTION
>
> # LOG ERROR
> }
>
>
> On Tue, May 30, 2017 at 4:47 AM, James Smith <js5@sanger.ac.uk> wrote:
>
> > Not really a mod_perl question but you can always wrap your method call in
> > an eval
> >
> > my $ret = eval { $m->...() };
> >
> > And then check $@ for the error message
> >
> >
> > On 2017-05-26 02:08 AM, Peng Yonghua wrote:
> >
> >> greeting,
> >>
> >> I am not so good at perl/modperl,:)
> >>
> >> In the handler, a method from a class was called, when something dies
> >> from within the method, what's the correct way the handler will take?
> >>
> >> for example, I wrote this API which works right if given a correct domain
> >> name:
> >>
> >> http://fenghe.org/domain/?d=yahoo.com
> >>
> >> server response:
> >> var data={"registration":"domain may be taken","domain":"yahoo.com"}
> >>
> >> If given a wrong domain name:
> >>
> >> http://fenghe.org/domain/?d=yahoo.nonexist
> >>
> >> The server returns 500.
> >>
> >> This is because, in the handler, I used this module (wrote also by me):
> >>
> >> http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.
> >> 03/lib/Net/Domain/Registration/Check.pm
> >>
> >> And in the module, croak like this was happened,
> >>
> >> croak "domain TLD not exists" unless tld_exists($tld);
> >>
> >> When handler meets the croak, it dies (I guess) and server returns 500.
> >>
> >> How will I make the full system work right? fix on handler, or the module
> >> itself?
> >>
> >> Thanks.
> >>
> >
> >
> >
> > --
> > The Wellcome Trust Sanger Institute is operated by Genome Research
> > Limited, a charity registered in England with number 1021457 and a company
> > registered in England with number 2742969, whose registered office is 215
> > Euston Road, London, NW1 2BE.
>
>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *john@lariat.co <john@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
Re: capture exception [ In reply to ]
I think my head just exploded in a cloud of purple smoke.

On Tue, May 30, 2017 at 10:03 AM, <pali@cpan.org> wrote:

> Hi!
>
> Please note that true value in $@ is *not* necessary condition for
> checking if error in eval occurred. And similarly empty string or logic
> false value in $@ is *not* necessary condition that eval succeeded.
>
> The only thing which is guaranteed is undef return value from eval in
> case it failed. So correct check is:
>
> my $success = eval {
> # MY CODE
> 1;
> };
>
> unless ($success) {
> # HANDLE ERROR, $@ may (but does not have to) contain error
> }
>
> "1;" in eval block is there to set $success to 1. In case MY CODE throw
> error, $success is set to undef by perl.
>
> Note that $@ is propagated back, so you should localize $@ before
> calling eval. This is especially required if MY CODE (or function called
> from MY CODE) calls also eval.
>
> So you can use this pattern:
>
> {
> local $@;
> eval {
> # MY CODE
> 1;
> } or do {
> # HANDLE ERROR in $@ (but may be undef!)
> };
> }
>
> If you do not write 1; then return value is taken from the last call in
> MY CODE. So if problem is also when last function return non zero, then
> you can remove "1;". You can also combine it with "and" block, but
> beware for and/or logical blocks:
>
> {
> local $@;
> eval {
> func_which_may_die_or_fail_with_zero();
> } and do {
> print "function succeeded\n";
> func_may_fail_with_zero();
> } or do {
> my $err = $@ || 'unknown error';
> warn "Error: $err\n";
> rollback();
> };
> }
>
> But I suggest to use module like Try::Tiny or Try::Catch which handle
> above eval and $@ logic for you and you can easily write:
>
> try {
> # MY CODE
> } catch {
> # HANDLE ERROR in $_ (may be undef!)
> my $err = $_ || 'unknown error';
> };
>
> On Tuesday 30 May 2017 09:39:53 John Dunlap wrote:
> > Yes, I do that extensively and it works perfectly. It's as close to a
> true
> > Try/Catch block as we have in the perl world. However, I *usually* do not
> > return values from it because I use this construct to control my database
> > transaction demarcation and using the return value from outside of the
> eval
> > wouldn't be inside the transaction. With that said, I have had to do it
> > from time to time and it works just fine. Also, it is advisable to copy
> the
> > contents of $@ into a separate variable immediately. My understanding is
> > that this can prevent some weird concurrency issues, under some
> conditions.
> > My general form looks something like this,
> >
> > my $return = eval {
> > # BEGIN DATABASE TRANSACTION
> >
> > # DO SOME STUFF
> >
> > # COMMIT DATA BASE TRANSACTION
> >
> > return 'SOME VALUE';
> > };
> >
> > if ($@) {
> > my $error = $@;
> >
> > # ROLLBACK DATABASE TRANSACTION
> >
> > # LOG ERROR
> > }
> >
> >
> > On Tue, May 30, 2017 at 4:47 AM, James Smith <js5@sanger.ac.uk> wrote:
> >
> > > Not really a mod_perl question but you can always wrap your method
> call in
> > > an eval
> > >
> > > my $ret = eval { $m->...() };
> > >
> > > And then check $@ for the error message
> > >
> > >
> > > On 2017-05-26 02:08 AM, Peng Yonghua wrote:
> > >
> > >> greeting,
> > >>
> > >> I am not so good at perl/modperl,:)
> > >>
> > >> In the handler, a method from a class was called, when something dies
> > >> from within the method, what's the correct way the handler will take?
> > >>
> > >> for example, I wrote this API which works right if given a correct
> domain
> > >> name:
> > >>
> > >> http://fenghe.org/domain/?d=yahoo.com
> > >>
> > >> server response:
> > >> var data={"registration":"domain may be taken","domain":"yahoo.com"}
> > >>
> > >> If given a wrong domain name:
> > >>
> > >> http://fenghe.org/domain/?d=yahoo.nonexist
> > >>
> > >> The server returns 500.
> > >>
> > >> This is because, in the handler, I used this module (wrote also by
> me):
> > >>
> > >> http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.
> > >> 03/lib/Net/Domain/Registration/Check.pm
> > >>
> > >> And in the module, croak like this was happened,
> > >>
> > >> croak "domain TLD not exists" unless tld_exists($tld);
> > >>
> > >> When handler meets the croak, it dies (I guess) and server returns
> 500.
> > >>
> > >> How will I make the full system work right? fix on handler, or the
> module
> > >> itself?
> > >>
> > >> Thanks.
> > >>
> > >
> > >
> > >
> > > --
> > > The Wellcome Trust Sanger Institute is operated by Genome Research
> > > Limited, a charity registered in England with number 1021457 and a
> company
> > > registered in England with number 2742969, whose registered office is
> 215
> > > Euston Road, London, NW1 2BE.
> >
> >
> >
> >
> > --
> > John Dunlap
> > *CTO | Lariat *
> >
> > *Direct:*
> > *john@lariat.co <john@lariat.co>*
> >
> > *Customer Service:*
> > 877.268.6667
> > support@lariat.co
>



--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: capture exception [ In reply to ]
On Tue, May 30, 2017 at 09:47:59AM +0100, James Smith wrote:
> Not really a mod_perl question but you can always wrap your method
> call in an eval
>
> my $ret = eval { $m->...() };
>
> And then check $@ for the error message
>


that is a security hole

>
> On 2017-05-26 02:08 AM, Peng Yonghua wrote:
> >greeting,
> >
> >I am not so good at perl/modperl,:)
> >
> >In the handler, a method from a class was called, when something
> >dies from within the method, what's the correct way the handler
> >will take?
> >
> >for example, I wrote this API which works right if given a correct
> >domain name:
> >
> >http://fenghe.org/domain/?d=yahoo.com
> >
> >server response:
> >var data={"registration":"domain may be taken","domain":"yahoo.com"}
> >
> >If given a wrong domain name:
> >
> >http://fenghe.org/domain/?d=yahoo.nonexist
> >
> >The server returns 500.
> >
> >This is because, in the handler, I used this module (wrote also by me):
> >
> >http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.03/lib/Net/Domain/Registration/Check.pm
> >
> >
> >And in the module, croak like this was happened,
> >
> >croak "domain TLD not exists" unless tld_exists($tld);
> >
> >When handler meets the croak, it dies (I guess) and server returns 500.
> >
> >How will I make the full system work right? fix on handler, or the
> >module itself?
> >
> >Thanks.
>
>
>
> --
> The Wellcome Trust Sanger Institute is operated by Genome Research
> Limited, a charity registered in England with number 1021457 and a
> company registered in England with number 2742969, whose registered
> office is 215 Euston Road, London, NW1 2BE.

--
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
Re: capture exception [ In reply to ]
How is it a security hole?

On Tue, May 30, 2017 at 10:41 AM, Ruben Safir <ruben@mrbrklyn.com> wrote:

> On Tue, May 30, 2017 at 09:47:59AM +0100, James Smith wrote:
> > Not really a mod_perl question but you can always wrap your method
> > call in an eval
> >
> > my $ret = eval { $m->...() };
> >
> > And then check $@ for the error message
> >
>
>
> that is a security hole
>
> >
> > On 2017-05-26 02:08 AM, Peng Yonghua wrote:
> > >greeting,
> > >
> > >I am not so good at perl/modperl,:)
> > >
> > >In the handler, a method from a class was called, when something
> > >dies from within the method, what's the correct way the handler
> > >will take?
> > >
> > >for example, I wrote this API which works right if given a correct
> > >domain name:
> > >
> > >http://fenghe.org/domain/?d=yahoo.com
> > >
> > >server response:
> > >var data={"registration":"domain may be taken","domain":"yahoo.com"}
> > >
> > >If given a wrong domain name:
> > >
> > >http://fenghe.org/domain/?d=yahoo.nonexist
> > >
> > >The server returns 500.
> > >
> > >This is because, in the handler, I used this module (wrote also by me):
> > >
> > >http://search.cpan.org/~pyh/Net-Domain-Registration-Check-
> 0.03/lib/Net/Domain/Registration/Check.pm
> > >
> > >
> > >And in the module, croak like this was happened,
> > >
> > >croak "domain TLD not exists" unless tld_exists($tld);
> > >
> > >When handler meets the croak, it dies (I guess) and server returns 500.
> > >
> > >How will I make the full system work right? fix on handler, or the
> > >module itself?
> > >
> > >Thanks.
> >
> >
> >
> > --
> > The Wellcome Trust Sanger Institute is operated by Genome Research
> > Limited, a charity registered in England with number 1021457 and a
> > company registered in England with number 2742969, whose registered
> > office is 215 Euston Road, London, NW1 2BE.
>
> --
> 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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: capture exception [ In reply to ]
Using eval is an unacceptable security bug for all online and public
access programs that aquire data from external non-secured sources.



On Tue, May 30, 2017 at 09:39:53AM -0400, John Dunlap wrote:
> Yes, I do that extensively and it works perfectly. It's as close to a true
> Try/Catch block as we have in the perl world. However, I *usually* do not
> return values from it because I use this construct to control my database
> transaction demarcation and using the return value from outside of the eval
> wouldn't be inside the transaction. With that said, I have had to do it
> from time to time and it works just fine. Also, it is advisable to copy the
> contents of $@ into a separate variable immediately. My understanding is
> that this can prevent some weird concurrency issues, under some conditions.
> My general form looks something like this,
>
> my $return = eval {
> # BEGIN DATABASE TRANSACTION
>
> # DO SOME STUFF
>
> # COMMIT DATA BASE TRANSACTION
>
> return 'SOME VALUE';
> };
>
> if ($@) {
> my $error = $@;
>
> # ROLLBACK DATABASE TRANSACTION
>
> # LOG ERROR
> }
>
>
> On Tue, May 30, 2017 at 4:47 AM, James Smith <js5@sanger.ac.uk> wrote:
>
> > Not really a mod_perl question but you can always wrap your method call in
> > an eval
> >
> > my $ret = eval { $m->...() };
> >
> > And then check $@ for the error message
> >
> >
> > On 2017-05-26 02:08 AM, Peng Yonghua wrote:
> >
> >> greeting,
> >>
> >> I am not so good at perl/modperl,:)
> >>
> >> In the handler, a method from a class was called, when something dies
> >> from within the method, what's the correct way the handler will take?
> >>
> >> for example, I wrote this API which works right if given a correct domain
> >> name:
> >>
> >> http://fenghe.org/domain/?d=yahoo.com
> >>
> >> server response:
> >> var data={"registration":"domain may be taken","domain":"yahoo.com"}
> >>
> >> If given a wrong domain name:
> >>
> >> http://fenghe.org/domain/?d=yahoo.nonexist
> >>
> >> The server returns 500.
> >>
> >> This is because, in the handler, I used this module (wrote also by me):
> >>
> >> http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.
> >> 03/lib/Net/Domain/Registration/Check.pm
> >>
> >> And in the module, croak like this was happened,
> >>
> >> croak "domain TLD not exists" unless tld_exists($tld);
> >>
> >> When handler meets the croak, it dies (I guess) and server returns 500.
> >>
> >> How will I make the full system work right? fix on handler, or the module
> >> itself?
> >>
> >> Thanks.
> >>
> >
> >
> >
> > --
> > The Wellcome Trust Sanger Institute is operated by Genome Research
> > Limited, a charity registered in England with number 1021457 and a company
> > registered in England with number 2742969, whose registered office is 215
> > Euston Road, London, NW1 2BE.
>
>
>
>
> --
> John Dunlap
> *CTO | Lariat *
>
> *Direct:*
> *john@lariat.co <john@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co



--
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
Re: capture exception [ In reply to ]
How so? How would an attacker exploit it?

On Tue, May 30, 2017 at 10:46 AM, Ruben Safir <ruben@mrbrklyn.com> wrote:

> Using eval is an unacceptable security bug for all online and public
> access programs that aquire data from external non-secured sources.
>
>
>
> On Tue, May 30, 2017 at 09:39:53AM -0400, John Dunlap wrote:
> > Yes, I do that extensively and it works perfectly. It's as close to a
> true
> > Try/Catch block as we have in the perl world. However, I *usually* do not
> > return values from it because I use this construct to control my database
> > transaction demarcation and using the return value from outside of the
> eval
> > wouldn't be inside the transaction. With that said, I have had to do it
> > from time to time and it works just fine. Also, it is advisable to copy
> the
> > contents of $@ into a separate variable immediately. My understanding is
> > that this can prevent some weird concurrency issues, under some
> conditions.
> > My general form looks something like this,
> >
> > my $return = eval {
> > # BEGIN DATABASE TRANSACTION
> >
> > # DO SOME STUFF
> >
> > # COMMIT DATA BASE TRANSACTION
> >
> > return 'SOME VALUE';
> > };
> >
> > if ($@) {
> > my $error = $@;
> >
> > # ROLLBACK DATABASE TRANSACTION
> >
> > # LOG ERROR
> > }
> >
> >
> > On Tue, May 30, 2017 at 4:47 AM, James Smith <js5@sanger.ac.uk> wrote:
> >
> > > Not really a mod_perl question but you can always wrap your method
> call in
> > > an eval
> > >
> > > my $ret = eval { $m->...() };
> > >
> > > And then check $@ for the error message
> > >
> > >
> > > On 2017-05-26 02:08 AM, Peng Yonghua wrote:
> > >
> > >> greeting,
> > >>
> > >> I am not so good at perl/modperl,:)
> > >>
> > >> In the handler, a method from a class was called, when something dies
> > >> from within the method, what's the correct way the handler will take?
> > >>
> > >> for example, I wrote this API which works right if given a correct
> domain
> > >> name:
> > >>
> > >> http://fenghe.org/domain/?d=yahoo.com
> > >>
> > >> server response:
> > >> var data={"registration":"domain may be taken","domain":"yahoo.com"}
> > >>
> > >> If given a wrong domain name:
> > >>
> > >> http://fenghe.org/domain/?d=yahoo.nonexist
> > >>
> > >> The server returns 500.
> > >>
> > >> This is because, in the handler, I used this module (wrote also by
> me):
> > >>
> > >> http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.
> > >> 03/lib/Net/Domain/Registration/Check.pm
> > >>
> > >> And in the module, croak like this was happened,
> > >>
> > >> croak "domain TLD not exists" unless tld_exists($tld);
> > >>
> > >> When handler meets the croak, it dies (I guess) and server returns
> 500.
> > >>
> > >> How will I make the full system work right? fix on handler, or the
> module
> > >> itself?
> > >>
> > >> Thanks.
> > >>
> > >
> > >
> > >
> > > --
> > > The Wellcome Trust Sanger Institute is operated by Genome Research
> > > Limited, a charity registered in England with number 1021457 and a
> company
> > > registered in England with number 2742969, whose registered office is
> 215
> > > Euston Road, London, NW1 2BE.
> >
> >
> >
> >
> > --
> > John Dunlap
> > *CTO | Lariat *
> >
> > *Direct:*
> > *john@lariat.co <john@lariat.co>*
> >
> > *Customer Service:*
> > 877.268.6667
> > support@lariat.co
>
>
>
> --
> 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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: capture exception [ In reply to ]
> On 30 May 2017, at 16:43, John Dunlap <john@lariat.co> wrote:
>
> How is it a security hole?
….
> > my $ret = eval { $m->...() };

Just imagine $m->…() returning something containing a valid perl expression such as " `rm -rf /‘; “, system(“rm -rf /“); or something that wires up a shell to a TCP socket.

Dw.
Re: capture exception [ In reply to ]
On Tuesday 30 May 2017 10:46:08 Ruben Safir wrote:
> Using eval is an unacceptable security bug for all online and public
> access programs that aquire data from external non-secured sources.

Eval is exception handling. It catch problems which could be security
problem (like DOS attack) to correctly handle errors and recover.

Correct and secure code, like in defensing programming, should handle
*all* possible errors which could come from external modules or external
sources and recover from error state. And tool for this is: eval.
Re: capture exception [ In reply to ]
https://www.effectiveperlprogramming.com/2011/03/know-the-different-evals/

On Tue, May 30, 2017 at 10:49 AM, Dirk-Willem van Gulik <
dirkx@webweaving.org> wrote:

>
> On 30 May 2017, at 16:43, John Dunlap <john@lariat.co> wrote:
>
> How is it a security hole?
>
> ….
>
> > my $ret = eval { $m->...() };
>
>
> Just imagine $m->…() returning something containing a valid perl
> expression such as " `rm -rf /‘; “, system(“rm -rf /“); or something that
> wires up a shell to a TCP socket.
>
> Dw.
>
>
Re: capture exception [ In reply to ]
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

{There are some good uses of string eval - e.g. dymanically "use"ing
modules}

James


On 2017-05-30 03:46 PM, Ruben Safir wrote:
> Using eval is an unacceptable security bug for all online and public
> access programs that aquire data from external non-secured sources.
>
>
>
> On Tue, May 30, 2017 at 09:39:53AM -0400, John Dunlap wrote:
>> Yes, I do that extensively and it works perfectly. It's as close to a true
>> Try/Catch block as we have in the perl world. However, I *usually* do not
>> return values from it because I use this construct to control my database
>> transaction demarcation and using the return value from outside of the eval
>> wouldn't be inside the transaction. With that said, I have had to do it
>> from time to time and it works just fine. Also, it is advisable to copy the
>> contents of $@ into a separate variable immediately. My understanding is
>> that this can prevent some weird concurrency issues, under some conditions.
>> My general form looks something like this,
>>
>> my $return = eval {
>> # BEGIN DATABASE TRANSACTION
>>
>> # DO SOME STUFF
>>
>> # COMMIT DATA BASE TRANSACTION
>>
>> return 'SOME VALUE';
>> };
>>
>> if ($@) {
>> my $error = $@;
>>
>> # ROLLBACK DATABASE TRANSACTION
>>
>> # LOG ERROR
>> }
>>
>>
>> On Tue, May 30, 2017 at 4:47 AM, James Smith <js5@sanger.ac.uk> wrote:
>>
>>> Not really a mod_perl question but you can always wrap your method call in
>>> an eval
>>>
>>> my $ret = eval { $m->...() };
>>>
>>> And then check $@ for the error message
>>>
>>>
>>> On 2017-05-26 02:08 AM, Peng Yonghua wrote:
>>>
>>>> greeting,
>>>>
>>>> I am not so good at perl/modperl,:)
>>>>
>>>> In the handler, a method from a class was called, when something dies
>>>> from within the method, what's the correct way the handler will take?
>>>>
>>>> for example, I wrote this API which works right if given a correct domain
>>>> name:
>>>>
>>>> http://fenghe.org/domain/?d=yahoo.com
>>>>
>>>> server response:
>>>> var data={"registration":"domain may be taken","domain":"yahoo.com"}
>>>>
>>>> If given a wrong domain name:
>>>>
>>>> http://fenghe.org/domain/?d=yahoo.nonexist
>>>>
>>>> The server returns 500.
>>>>
>>>> This is because, in the handler, I used this module (wrote also by me):
>>>>
>>>> http://search.cpan.org/~pyh/Net-Domain-Registration-Check-0.
>>>> 03/lib/Net/Domain/Registration/Check.pm
>>>>
>>>> And in the module, croak like this was happened,
>>>>
>>>> croak "domain TLD not exists" unless tld_exists($tld);
>>>>
>>>> When handler meets the croak, it dies (I guess) and server returns 500.
>>>>
>>>> How will I make the full system work right? fix on handler, or the module
>>>> itself?
>>>>
>>>> Thanks.
>>>>
>>>
>>>
>>> --
>>> The Wellcome Trust Sanger Institute is operated by Genome Research
>>> Limited, a charity registered in England with number 1021457 and a company
>>> registered in England with number 2742969, whose registered office is 215
>>> Euston Road, London, NW1 2BE.
>>
>>
>>
>> --
>> John Dunlap
>> *CTO | Lariat *
>>
>> *Direct:*
>> *john@lariat.co <john@lariat.co>*
>>
>> *Customer Service:*
>> 877.268.6667
>> support@lariat.co
>
>



--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Re: capture exception [ In reply to ]
On 2017-05-30 03:49 PM, Dirk-Willem van Gulik wrote:
>
>> On 30 May 2017, at 16:43, John Dunlap <john@lariat.co
>> <mailto:john@lariat.co>> wrote:
>>
>> How is it a security hole?
> ….
>>
>> > my $ret = eval { $m->...() };
>>
>
> Just imagine $m->…() returning something containing a valid perl
> expression such as " `rm -rf /‘; “, system(“rm -rf /“); or something
> that wires up a shell to a TCP socket.
>
> Dw.
>
But that isn't how it works - the "{" "}" brace means $m->...() is run -
but the output is trapped... the two types of eval are different....



--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
Re: capture exception [ In reply to ]
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.

> {There are some good uses of string eval - e.g. dymanically "use"ing
> modules}

That is wrong too. If you need to load module dynamically do it also
without stringified eval, to ensure security (somebody can include ';'
into module name...). It is done by "require" and "import". But easier
would be to use Module::Runtime which calls "require" correctly for you:
https://metacpan.org/pod/Module::Runtime

> James
Re: capture exception [ In reply to ]
> On 30 May 2017, at 16:58, pali@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.
Re: capture exception [ In reply to ]
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 <
dirkx@webweaving.org> wrote:

>
> > On 30 May 2017, at 16:58, pali@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
hgibbard@gmail.com
http://hiramgibbard.com
Re: capture exception [ In reply to ]
At the risk of oversimplifying the issue:
BAD: eval "MY CODE";
GOOD: eval {MY CODE};

On Tue, May 30, 2017 at 12:00 PM, Hiram Gibbard <hgibbard@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 <
> dirkx@webweaving.org> wrote:
>
>>
>> > On 30 May 2017, at 16:58, pali@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
> hgibbard@gmail.com
> http://hiramgibbard.com
>
>


--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: capture exception [ In reply to ]
It is only a security hole if you eval user input.


--
Clive Eisen
GPG: 75056DD0






> On 30 May 2017, at 17:00, Hiram Gibbard <hgibbard@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 <dirkx@webweaving.org <mailto:dirkx@webweaving.org>> wrote:
>
> > On 30 May 2017, at 16:58, pali@cpan.org <mailto:pali@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
> hgibbard@gmail.com <mailto:hgibbard@gmail.com>
> http://hiramgibbard.com <http://hiramgibbard.com/>
>
Re: capture exception [ In reply to ]
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 <hgibbard@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 <dirkx@webweaving.org <mailto:dirkx@webweaving.org>> wrote:
> >
> > > On 30 May 2017, at 16:58, pali@cpan.org <mailto:pali@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
> > hgibbard@gmail.com <mailto:hgibbard@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
Re: capture exception [ In reply to ]
>
>
> I was just reading everyone's reply and now I am worried I created a
> security hole.
>

eval will randomly execute ANY externally aquired string and run it with
the full power and authority of Perl and your webserver.

Nothing but static strings of known perl code should be using eval...
actually it is better to just not use eval. Error checking can be done
on the fly and code that fails for some reason should end the process.

Apache will rekick an instance anyway.


> Thanks
>
> On Tue, May 30, 2017 at 10:04 AM, Dirk-Willem van Gulik <
> dirkx@webweaving.org> wrote:
>
> >
> > > On 30 May 2017, at 16:58, pali@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
> hgibbard@gmail.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
Re: capture exception [ In reply to ]
From my servers - data

From anyone else's - user input

--
Clive Eisen
GPG: 75056DD0






> On 30 May 2017, at 18:47, Ruben Safir <ruben@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 <hgibbard@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 <dirkx@webweaving.org <mailto:dirkx@webweaving.org> <mailto:dirkx@webweaving.org <mailto:dirkx@webweaving.org>>> wrote:
>>>
>>>> On 30 May 2017, at 16:58, pali@cpan.org <mailto:pali@cpan.org> <mailto:pali@cpan.org <mailto:pali@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
>>> hgibbard@gmail.com <mailto:hgibbard@gmail.com> <mailto:hgibbard@gmail.com <mailto:hgibbard@gmail.com>>
>>> http://hiramgibbard.com <http://hiramgibbard.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 <http://www.mrbrklyn.com/>
>
> DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
> http://www.nylxs.com <http://www.nylxs.com/> - Leadership Development in Free Software
> http://www2.mrbrklyn.com/resources <http://www2.mrbrklyn.com/resources> - Unpublished Archive
> http://www.coinhangout.com <http://www.coinhangout.com/> - coins!
> http://www.brooklyn-living.com <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
Re: capture exception [ In reply to ]
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 <ruben@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 <hgibbard@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 <
> dirkx@webweaving.org <mailto:dirkx@webweaving.org>> wrote:
> > >
> > > > On 30 May 2017, at 16:58, pali@cpan.org <mailto:pali@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
> > > hgibbard@gmail.com <mailto:hgibbard@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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: capture exception [ In reply to ]
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 <john@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 <ruben@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 <hgibbard@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 <
>> dirkx@webweaving.org <mailto:dirkx@webweaving.org>> wrote:
>> > >
>> > > > On 30 May 2017, at 16:58, pali@cpan.org <mailto:pali@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
>> > > hgibbard@gmail.com <mailto:hgibbard@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:*
> *john@lariat.co <john@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
>



--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: capture exception [ In reply to ]
On 30 May 2017, at 19:52, Clive Eisen <clive@hildebrand.co.uk> wrote:

> From my servers - data
>
> From anyone else's - user input

A few years ago - I would have agreed. Having seen the impact of things like the bash-exploit getting triggered from the data returned by a IP reverse lookup - I am not so sure anymore,

Dw.

1 2  View All