Skip Menu |
 

This queue is for tickets about the Crypt-SSLeay CPAN distribution.

Report information
The Basics
Id: 4759
Status: resolved
Priority: 0/
Queue: Crypt-SSLeay

People
Owner: dland [...] cpan.org
Requestors: jeff [...] forristal.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.51
Fixed in: (no value)



Subject: get_lwp_object() called from proxy_connect_helper causes error
Download (untitled) / with headers
text/plain 628b
When Net::SSL is used with a proxy, proxy_connect_helper() calls get_lwp_object(). Get_lwp_object() traverses up the call stack and runs isa() on every 1st function argument reference. It is traversing very far up into my program, which passes unblessed anonymous hashes in some places as function parameters...and isa() causes an immediate abort since the anonymous hashes are unblessed. So either the isa() needs to be wrapped in an eval{}, or the program has to be a little more courteous as to how far it's going to trace back in order to not puke on perfectly-acceptable function parameters used within the calling app.
Download (untitled) / with headers
text/plain 1002b
On Fri Dec 26 19:35:14 2003, guest wrote: Show quoted text
> When Net::SSL is used with a proxy, proxy_connect_helper() calls > get_lwp_object(). Get_lwp_object() traverses up the call stack and > runs isa() on every 1st function argument reference. It is > traversing very far up into my program, which passes unblessed > anonymous hashes in some places as function parameters...and isa() > causes an immediate abort since the anonymous hashes are unblessed. > > So either the isa() needs to be wrapped in an eval{}, or the program > has to be a little more courteous as to how far it's going to trace > back in order to not puke on perfectly-acceptable function > parameters used within the calling app.
Hello, I am the new maintainer for Crypt-SSLeay. Is this problem still an issue? Can you produce a small test case? Ideally something I can add to the test suite to make sure the module is behaving according to spec? Thanks, David -- The Lusty Decadent Delights of Imperial Pompeii
Subject: Re: [rt.cpan.org #4759] get_lwp_object() called from proxy_connect_helper causes error
Date: Wed, 20 Dec 2006 17:38:32 -0500
To: bug-Crypt-SSLeay [...] rt.cpan.org
From: Jeff Forristal <jeff [...] forristal.com>
Download (untitled) / with headers
text/plain 3.5k
Tested on: $Net::SSL::VERSION: 2.77 ($Crypt::SSLeay::VERSION: 0.51) Test case: ################################################################ #!perl use Net::SSL; $hash_ref = { 'foo' => 'bar' }; mysub($hash_ref); sub mysub { my $hr = shift; $ENV{'HTTPS_PROXY'} = 'localhost:8080'; $sock = Net::SSL->new( PeerAddr => 'www.microsoft.com', PeerPort => 443, Timeout => 10 ); } ################################################################ This dies with error: proxy connect failed: Can't call method "isa" on unblessed reference at ...\Net\SSL.pm line 320. The problem stems from get_lwp_object() running isa() on the first parameter of every function call on the stack. In this case, it is running isa() on the parameter to mysub(). Since that parameter is an unblessed hash reference, isa() dies with the above error. I can think of a few ways to fix this. The easiest is probably to wrap the isa() in an eval{}. Another is to check to see if the parameter is an unblessed reference (HASH, ARRAY, SCALAR, etc.) and shortcut out before running isa() (you'd have to know the full list of possible unblessed reference types and hard-code them in for this to work, and it might not be future-proof if a new native type is added to Perl). Also, I haven't traced the use of Net::SSL in relation to LWP, but if the execution path always has LWP calling Net::SSL (and Net::SSL is then trying to backtrack up the stack and find the LWP object), then perhaps you can limit the checks in get_lwp_object() to only happen if the package namespace for the caller is 'LWP'. Also, the currently implemented behavior could lead to problems, if for some reason the calling application happens to pass an unrelated LWP object somewhere up the call stack. The current get_lwp_object() will traverse up the entire stack and grab any LWP object encountered, whether or not it has any context or bearing to the actual call to Net::SSL down the road. Imagine someone implementing a conversion function which converts/extracts an LWP object to a set of data values, changes some of the values, and then calls Net::SSL with those new values. Net::SSL will traverse up through the call stack, past the conversion function, and slurp values out of the original LWP object prior to conversion. And of all this is merely to be able to send a User-Agent string to the *proxy* server (not the web server itself), which is a very minor functional benefit. The potential and actual ramifications seem to outweigh the minimal benefit, IMHO. Thanks, - J David Landgren via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=4759 > > > On Fri Dec 26 19:35:14 2003, guest wrote:
>> When Net::SSL is used with a proxy, proxy_connect_helper() calls >> get_lwp_object(). Get_lwp_object() traverses up the call stack and >> runs isa() on every 1st function argument reference. It is >> traversing very far up into my program, which passes unblessed >> anonymous hashes in some places as function parameters...and isa() >> causes an immediate abort since the anonymous hashes are unblessed. >> >> So either the isa() needs to be wrapped in an eval{}, or the program >> has to be a little more courteous as to how far it's going to trace >> back in order to not puke on perfectly-acceptable function >> parameters used within the calling app.
> > Hello, > > I am the new maintainer for Crypt-SSLeay. Is this problem still an > issue? Can you produce a small test case? Ideally something I can add to > the test suite to make sure the module is behaving according to spec? > > Thanks, > David >
Subject: Re: [rt.cpan.org #4759] get_lwp_object() called from proxy_connect_helper causes error
Date: Wed, 20 Dec 2006 16:38:49 -0800
To: bug-Crypt-SSLeay [...] rt.cpan.org
From: Joshua Chamas <josh [...] chamas.com>
Download (untitled) / with headers
text/plain 1.2k
Hi David, You seem to be doing well at taking over Crypt::SSLeay. If this works well, then you should run with it. Cheers, Josh David Landgren via RT wrote: Show quoted text
> Queue: Crypt-SSLeay > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=4759 > > > On Fri Dec 26 19:35:14 2003, guest wrote:
>> When Net::SSL is used with a proxy, proxy_connect_helper() calls >> get_lwp_object(). Get_lwp_object() traverses up the call stack and >> runs isa() on every 1st function argument reference. It is >> traversing very far up into my program, which passes unblessed >> anonymous hashes in some places as function parameters...and isa() >> causes an immediate abort since the anonymous hashes are unblessed. >> >> So either the isa() needs to be wrapped in an eval{}, or the program >> has to be a little more courteous as to how far it's going to trace >> back in order to not puke on perfectly-acceptable function >> parameters used within the calling app.
> > Hello, > > I am the new maintainer for Crypt-SSLeay. Is this problem still an > issue? Can you produce a small test case? Ideally something I can add to > the test suite to make sure the module is behaving according to spec? > > Thanks, > David >
Download (untitled) / with headers
text/plain 370b
I have uploaded Crypt-SSLeay-0.53_02, which contains a patch to resolve this problem. I agree with the analysis: the existing code was rather fragile. By default, the behaviour is no longer to perform the caller stack walk to locate a lwp object, but can be enabled explicitly if people so desire. Can you take it for a spin and let me know how it goes? Regards, David
Download (untitled) / with headers
text/plain 189b
This bug has been resolved in 0.53_03. If no other issues arise from this latest release, an official 0.54 release will be made in the next couple of weeks. Thanks for your patience, David


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.