Bug #26401 for Crypt-SSLeay: connect() never times out

Mon Apr 16 07:25:46 2007 pts [...] fazekas.hu - Ticket created

Subject:

connect() never times out

Due to `sub Net::HTTPS::blocking {}' always returning false, the connect() in Net::SSL never times out. The attached patch fixes the problem.

Subject:

pts-net-ssl-connect-blocking.patch

--- Net/SSL.pm.orig 2007-04-16 13:11:15.000000000 +0200 +++ Net/SSL.pm 2007-04-16 13:10:45.000000000 +0200 @@ -91,20 +91,21 @@ if ($self->proxy) { # don't die() in connect, just return undef and set $@ my $proxy_connect = eval { $self->proxy_connect_helper(@_); }; if(! $proxy_connect || $@) { $@ = "proxy connect failed: $@; $!"; die $@; } } else { *$self->{io_socket_peername}=@_ == 1 ? $_[0] : IO::Socket::sockaddr_in(@_); + local *Net::HTTPS::blocking; #### pts #### Dat: otherwise `sub Net::HTTPS::blocking { }' would prevent the proper timeout if(!$self->SUPER::connect(@_)) { # better to die than return here $@ = "Connect failed: $@; $!"; die $@; } } # print "ssl_version ".*$self->{ssl_version}."\n"; my $debug = *$self->{'ssl_debug'} || 0; my $ssl = Crypt::SSLeay::Conn->new(*$self->{'ssl_ctx'}, $debug, $self);

Sat May 05 04:42:06 2007 dland [...] cpan.org - Taken

Sat May 05 04:43:04 2007 dland [...] cpan.org - Correspondence added

On Mon Apr 16 07:25:46 2007, PTS wrote: Show quoted text

> Due to `sub Net::HTTPS::blocking {}' always returning false, the > connect() in Net::SSL never times out. The attached patch fixes the

problem. Thanks for this patch, and sorry about taking so much time to respond. I have a couple of patches to roll into a new release. Later, David

Sat May 05 04:43:05 2007 The RT System itself - Status changed from 'new' to 'open'

Mon May 07 07:42:42 2007 dland [...] cpan.org - Correspondence added

From:

dland [...] cpan.org

On Mon Apr 16 07:25:46 2007, PTS wrote: Show quoted text

> Due to `sub Net::HTTPS::blocking {}' always returning false, the > connect() in Net::SSL never times out. The attached patch fixes the

problem. I've had the time to analyse this patch and I have a couple of issues with it. Firstly, in the Net::HTTPS module, the following comment appears: # The underlying SSLeay classes fails to work if the socket is # placed in non-blocking mode. This override of the blocking # method makes sure it stays the way it was created. Now I'm not sure whether this is for historical purposes, given that most people these days are using OpenSSL libraries. So I'm not sure it's wise to short-circuit the current provisions for not permitting non-blocking sockets. Be that as it may, as you point out the need to be able to do just this, I think a better idea is to expose the underlying IO::Socket::INET::blocking setting through the Net::SSL interface, and thus let client code reconfigure the blocking setting as they see fit. How does this sound to you? Regards, David Landgren

Fri Jun 01 13:46:42 2007 dland [...] cpan.org - Correspondence added

I have uploaded version 0.55, which adds a blocking() method. This should let you do what you want. I'm therefore closing this bug, since I haven't heard back from you regarding the approach. Feel free to reply if there's something else that needs to be done. Regards, David

Fri Jun 01 13:46:49 2007 dland [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Jun 04 20:00:24 2007 pts [...] fazekas.hu - Correspondence added

From:

pts [...] fazekas.hu

Sorry for not replying earlier. The project for which we needed HTTPS connect() with timeout is over now. If we experience any further problems, I'll let you know. Best regards, PTS

Mon Jun 04 20:00:46 2007 The RT System itself - Status changed from 'resolved' to 'open'

Tue Jun 05 07:14:25 2007 dland [...] cpan.org - Status changed from 'open' to 'resolved'