Bug #78695 for Crypt-SSLeay: Paypal / Actinic / SellerDeck

Tue Jul 31 12:43:32 2012 tim [...] smdcomputers.com - Ticket created

Subject:	Paypal / Actinic / SellerDeck
Date:	Tue, 31 Jul 2012 17:43:19 +0100
To:	bug-Crypt-SSLeay [...] rt.cpan.org
From:	Timothy O'Brien <tim [...] smdcomputers.com>

I would like to report a fault with Crypt-SSLeay 0.60 and 0.60.01 When the server upgraded to Crypt-SSLeay 0.60 this error appears in the error_log file for apache: [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] read failed: at al000001.pm line 377, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Net/SSL.pm line 215, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tNet::SSL::die_with_error('Net::SSL=GLOB(0x8eae2a0)', 'read failed') called at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Net/SSL.pm line 228, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tNet::SSL::read('Net::SSL=GLOB(0x8eae2a0)', 'HTTP/1.1 200 OK\\x{d}\\x{a}Date: Tue, 31 Jul 2012 11:14:44 GMT\\x{d}\\x{a}Server:...', 1024) called at al000001.pm line 377, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tACTINIC::HTTPS_SendAndReceive('api-3t.paypal.com', 443, '/nvp', 'PWD=52YZ5JG9969EWQSS&USER=susan_api1%2ebrand%2euk%2ecom&SIGNA...', 'POST', 1, 'undef', 'Connection: close\\x{d}\\x{a}X-VPS-REQUEST-ID: 0.778850956660794\\x{d}\\x{a}User-...') called at al000001.pm line 4936, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tSSLConnection::SendRequest('SSLConnection=HASH(0x8d22774)', 'PWD=52YZ5JG9969EWQSS&USER=susan_api1%2ebrand%2euk%2ecom&SIGNA...') called at (eval 30) line 760, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tActinicPaypalConnection::SendRequest('ActinicPaypalConnection=HASH(0x8d227bc)') called at (eval 30) line 928, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tActinicPaypalConnection:oStartCheckout('ActinicPaypalConnection=HASH(0x8d227bc)', 12) called at (eval 30) line 83, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tmain::StartPaypalProCheckout() called at os000001.pl line 332, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] \tmain::ProcessInput() called at os000001.pl line 68, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] Premature end of script headers: os000001.pl, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> [Tue Jul 31 12:14:41 2012] [error] [client 86.16.69.172] File does not exist: /home/themill/public_html/500.shtml, referer: http://www.embroiderymill.co.uk/cgi-...2findex%2ehtml <http://www.embroiderymill.co.uk/cgi-bin/os000001.pl?ACTION=Start&REFPAGE=http%3a%2f%2fembroiderymill%2eco%2euk%2findex%2ehtml> When downgrading to 0.58 the actinic website passes to paypal and works. Tested on several servers already and confirmed working when version is at 0.58 -- Tim O'Brien Trading terms & conditions apply Managing Director SMD Computers LTD Reg Number : 7523760 B30, The Sanderson Centre 15 Lees Lane Gosport Hampshire PO12 3UL T: 0844 414 0403 Mob: 07887722356 W: http://smdcomputers.com

Download biggrin.gif
image/gif 1k

Tue Jul 31 13:54:16 2012 nanis [...] runu.moc.invalid - Taken

Tue Jul 31 13:59:14 2012 nanis [...] runu.moc.invalid - Correspondence added

Hello Tim: Thank you for the log file and the additional information from the Actinic / SellerDeck support people. Please post any further communication on RT either by responding to this message or visiting <https://rt.cpan.org/Public/Bug/Display.html?id=78695> As for: Show quoted text

> The code has worked the same way for as long as > I can remember (at least 10 years). No idea why > it should be changed now.

I was trying to fix bugs related to incomplete reads/writes reported on RT. I think I understand the mistake I made, but 0.59_03, which had the change, had been out for months so I figured it was safe to release it now. I will give you a heads up when I have a fix. Thank you. -- Sinan

Tue Jul 31 13:59:15 2012 The RT System itself - Status changed from 'new' to 'open'

Tue Jul 31 15:01:26 2012 nanis [...] runu.moc.invalid - Correspondence added

On Tue Jul 31 13:59:14 2012, NANIS wrote: Show quoted text

> Hello Tim: > > Thank you for the log file and the additional information from the > Actinic / SellerDeck support people. > > Please post any further communication on RT either by responding to this > message or visiting <https://rt.cpan.org/Public/Bug/Display.html?id=78695> > > As for: >

> > The code has worked the same way for as long as > > I can remember (at least 10 years). No idea why > > it should be changed now.

> > I was trying to fix bugs related to incomplete reads/writes reported on > RT. I think I understand the mistake I made, but 0.59_03, which had the > change, had been out for months so I figured it was safe to release it

now. Show quoted text

> > I will give you a heads up when I have a fix. > > Thank you. > > -- Sinan

Tue Jul 31 15:15:10 2012 nanis [...] runu.moc.invalid - Correspondence added

Just FYI. Looking at: Net::SSL::die_with_error('Net::SSL=GLOB(0x8eae2a0)', 'read failed') called at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/Net/SSL.pm line 228 Net::SSL::read('Net::SSL=GLOB(0x8eae2a0) HTTP/1.1 200 OK\\x{d}\\x{a} Date: Tue, 31 Jul 2012 11:14:44 GMT\\x{d}\\x{a} Server:...', 1024) called at al000001.pm line 377 ACTINIC::HTTPS_SendAndReceive('api-3t.paypal.com', 443, '/nvp', '') called at al000001.pm line 4936, SSLConnection::SendRequest('SSLConnection=HASH(0x8d22774)', ''); called at (eval 30) line 760 ActinicPaypalConnection::SendRequest('ActinicPaypalConnection=HASH(0x8d227bc)') called at (eval 30) line 928, ActinicPaypalConnection:oStartCheckout('ActinicPaypalConnection=HASH(0x8d227bc)',12) called at (eval 30) line 83 main::StartPaypalProCheckout() called at os000001.pl line 332, main::ProcessInput() called at os000001.pl line 68, I am lead to believe that Actinic uses Net::SSL as a generic secure sockets library rather than in conjunction with LWP. To be honest, as far as I understand things, that is outside of the expected use case. Crypt::SSLeay is supposed to provide SSL support for LWP, and applications are supposed to make their requests using LWP instead of using a home-brewed replacement for LWP. I am trying to replicate the problem using LWP, but I thought I would point this out. -- Sinan

Tue Jul 31 15:50:37 2012 tim [...] smdcomputers.com - Correspondence added

Subject:	Re: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck
Date:	Tue, 31 Jul 2012 20:50:30 +0100
To:	bug-Crypt-SSLeay [...] rt.cpan.org
From:	Timothy O'Brien <tim [...] smdcomputers.com>

I think _03 development cpans do not get updated to CPANEL releases, only the major ones do. I had to manually install 0.60_01 to check to see if the fault was still there. Tim O'Brien Trading terms & conditions apply Managing Director SMD Computers LTD Reg Number : 7523760 B30, The Sanderson Centre 15 Lees Lane Gosport Hampshire PO12 3UL T: 0844 414 0403 Mob: 07887722356 W: http://smdcomputers.com On 31/07/2012 18:59, A. Sinan Unur via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > > > Hello Tim: > > Thank you for the log file and the additional information from the > Actinic / SellerDeck support people. > > Please post any further communication on RT either by responding to this > message or visiting <https://rt.cpan.org/Public/Bug/Display.html?id=78695> > > As for: >

>> The code has worked the same way for as long as >> I can remember (at least 10 years). No idea why >> it should be changed now.

> I was trying to fix bugs related to incomplete reads/writes reported on > RT. I think I understand the mistake I made, but 0.59_03, which had the > change, had been out for months so I figured it was safe to release it now. > > I will give you a heads up when I have a fix. > > Thank you. > > -- Sinan

Wed Aug 01 06:32:34 2012 gordon.camley [...] sellerdeck.co.uk - Correspondence added

From:

gordon.camley [...] sellerdeck.co.uk

As the Sellerdeck developer that discovered the problem I'd like to add some background that may assist in deciding whether this is a bug in Crypt::SSLeay that needs fixing. You are correct we do not use Net::SSL via LWP. However we have been using Net::SSL for many years without any problems. The code that failed is unchanged for many years and is simply:- $ssl_socket->print($sData); my $buf =''; while ($ssl_socket->read($buf, 1024)) { $sResponse .= $buf; } This worked as the eventually read() returns zero. Now it reads the last block of data and the next read causes the script error. I worked round this by coding the above as:- $ssl_socket->print($sData); my $buf =''; my ($nBuf) = 1024; while ($nBuf == 1024) { $nBuf = $ssl_socket->read($buf, 1024); $sResponse .= $buf; } This will now stop reading if the last block read is shorter than the block size. This however will still fail if the last block read is in fact equal in size to the buffer. If there is now a more reliable way of determining when the end of the data has been reached then we shall gladly implement it.

Wed Aug 01 10:56:06 2012 nanis [...] runu.moc.invalid - Correspondence added

RT-Send-CC:

nanis [...] cpan.org, gordon.camley [...] sellerdeck.co.uk

Hello: I am still somewhat unsure about this but I would appreciate it if you could give the attached version a shot. I've uploaded it to CPAN, but it will take about an hour for it to propagate. Thank you. -- Sinan On Wed Aug 01 06:32:34 2012, gcamley wrote: Show quoted text

> As the Sellerdeck developer that discovered the problem I'd like to add > some background that may assist in deciding whether this is a bug in > Crypt::SSLeay that needs fixing. > > You are correct we do not use Net::SSL via LWP. However we have been > using Net::SSL for many years without any problems. > > The code that failed is unchanged for many years and is simply:- > > $ssl_socket->print($sData); > > my $buf =''; > while ($ssl_socket->read($buf, 1024)) > { > $sResponse .= $buf; > } > > This worked as the eventually read() returns zero. Now it reads the last > block of data and the next read causes the script error. > > I worked round this by coding the above as:- > > $ssl_socket->print($sData); > > my $buf =''; > my ($nBuf) = 1024; > while ($nBuf == 1024) > { > $nBuf = $ssl_socket->read($buf, 1024); > $sResponse .= $buf; > } > > This will now stop reading if the last block read is shorter than the > block size. This however will still fail if the last block read is in > fact equal in size to the buffer. > > If there is now a more reliable way of determining when the end of the > data has been reached then we shall gladly implement it.

Subject:

Crypt-SSLeay-0.61_02.tar.gz

Download Crypt-SSLeay-0.61_02.tar.gz
application/x-gzip 125.3k

Message body not shown because it is not plain text.

Wed Aug 01 12:19:33 2012 gordon.camley [...] sellerdeck.co.uk - Correspondence added

Subject:	RE: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck
Date:	Wed, 1 Aug 2012 19:18:59 +0300
To:	<bug-Crypt-SSLeay [...] rt.cpan.org>
From:	"Gordon Camley" <gordon.camley [...] sellerdeck.co.uk>

Thanks Sinan for the prompt repsponse. I'll try the new version this evening. Best regards Gordon Camley 3rd Line Support SellerDeck Ltd. Registered Office (Globe House Lavender Park Road, West Byfleet, Surrey KT14 6ND) Company Registration No. 3221222 VAT no. GB834853604 Show quoted text

-----Original Message----- From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] Sent: Wednesday, August 01, 2012 5:56 PM Cc: nanis@cpan.org; gordon.camley@sellerdeck.co.uk Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > Hello: I am still somewhat unsure about this but I would appreciate it if you could give the attached version a shot. I've uploaded it to CPAN, but it will take about an hour for it to propagate. Thank you. -- Sinan On Wed Aug 01 06:32:34 2012, gcamley wrote:

> As the Sellerdeck developer that discovered the problem I'd like to add > some background that may assist in deciding whether this is a bug in > Crypt::SSLeay that needs fixing. > > You are correct we do not use Net::SSL via LWP. However we have been > using Net::SSL for many years without any problems. > > The code that failed is unchanged for many years and is simply:- > > $ssl_socket->print($sData); > > my $buf =''; > while ($ssl_socket->read($buf, 1024)) > { > $sResponse .= $buf; > } > > This worked as the eventually read() returns zero. Now it reads the last > block of data and the next read causes the script error. > > I worked round this by coding the above as:- > > $ssl_socket->print($sData); > > my $buf =''; > my ($nBuf) = 1024; > while ($nBuf == 1024) > { > $nBuf = $ssl_socket->read($buf, 1024); > $sResponse .= $buf; > } > > This will now stop reading if the last block read is shorter than the > block size. This however will still fail if the last block read is in > fact equal in size to the buffer. > > If there is now a more reliable way of determining when the end of the > data has been reached then we shall gladly implement it.

Wed Aug 01 17:55:08 2012 gordon.camley [...] sellerdeck.co.uk - Correspondence added

Subject:	RE: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck
Date:	Thu, 2 Aug 2012 00:54:30 +0300
To:	<bug-Crypt-SSLeay [...] rt.cpan.org>
From:	"Gordon Camley" <gordon.camley [...] sellerdeck.co.uk>

Hi Sinan, I can't build the module. I'm using perl 5.8 and I get [root@testapache Crypt-SSLeay-0.61_02]# perl Makefile.PL ======================================================= Only one OpenSSL installation found at /usr Consider running 'perl Makefile.PL --default' the next time Crypt::SSLeay is upgraded to select this directory automatically thereby avoiding the following prompt. ======================================================= Which SSL install path do you want to use? [/usr] BUILD INFORMATION ================================================ ssl library: OpenSSL 0.9.7a in /usr ssl header: openssl/ssl.h libraries: -L/usr/lib -lssl -lcrypto -lgcc include dir: -I/usr/include -I/usr/kerberos/include ================================================ WARNING: AUTHOR takes a string/number not a ARRAY reference. Please inform the author. Checking if your kit is complete... Looks good Warning: prerequisite LWP::Protocol::https 6.02 not found. We have unknown version. Note (probably harmless): No library found for -lgcc only nested arrays of non-refs are supported at /usr/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm line 664 [root@testapache Crypt-SSLeay-0.61_02]# I was able to insall Crypt-SSLeay-0.60 from CPAN on the same server without any trouble. Crypt-SSLeay-0.60 Makefile.PL reported the 2 lines:- Warning: prerequisite LWP::Protocol::https 6.02 not found. We have unknown version. Note (probably harmless): No library found for -lgcc But not only nested arrays of non-refs are supported at /usr/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm line 664 Best regards Gordon Camley 3rd Line Support SellerDeck Ltd. Registered Office (Globe House Lavender Park Road, West Byfleet, Surrey KT14 6ND) Company Registration No. 3221222 VAT no. GB834853604 Show quoted text

-----Original Message----- From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] Sent: Wednesday, August 01, 2012 5:56 PM Cc: nanis@cpan.org; gordon.camley@sellerdeck.co.uk Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > Hello: I am still somewhat unsure about this but I would appreciate it if you could give the attached version a shot. I've uploaded it to CPAN, but it will take about an hour for it to propagate. Thank you. -- Sinan On Wed Aug 01 06:32:34 2012, gcamley wrote:

> As the Sellerdeck developer that discovered the problem I'd like to add > some background that may assist in deciding whether this is a bug in > Crypt::SSLeay that needs fixing. > > You are correct we do not use Net::SSL via LWP. However we have been > using Net::SSL for many years without any problems. > > The code that failed is unchanged for many years and is simply:- > > $ssl_socket->print($sData); > > my $buf =''; > while ($ssl_socket->read($buf, 1024)) > { > $sResponse .= $buf; > } > > This worked as the eventually read() returns zero. Now it reads the last > block of data and the next read causes the script error. > > I worked round this by coding the above as:- > > $ssl_socket->print($sData); > > my $buf =''; > my ($nBuf) = 1024; > while ($nBuf == 1024) > { > $nBuf = $ssl_socket->read($buf, 1024); > $sResponse .= $buf; > } > > This will now stop reading if the last block read is shorter than the > block size. This however will still fail if the last block read is in > fact equal in size to the buffer. > > If there is now a more reliable way of determining when the end of the > data has been reached then we shall gladly implement it.

Wed Aug 01 18:00:11 2012 nanis [...] runu.moc.invalid - Correspondence added

Aaaarrrrgggghhhh!!!! That had been a long-standing thing -- giving all previous authors credit. I forgot that I had also done that before fiddling with this. I should have branched from an earlier commit. Apparently, your ExtUtils::MakeMaker is rather old. Anyway ... Could you just edit Makefile.PL and replace the array ref for AUTHOR in the WriteMakefile call with a scalar, any scalar? I am on a phone call right now, and it might be too late in the UK by the time I get done. -- Sinan On Wed Aug 01 17:55:08 2012, gcamley wrote: Show quoted text

> Hi Sinan, > > I can't build the module. > I'm using perl 5.8 and I get > > [root@testapache Crypt-SSLeay-0.61_02]# perl Makefile.PL > ======================================================= > Only one OpenSSL installation found at /usr > Consider running 'perl Makefile.PL --default' the next > time Crypt::SSLeay is upgraded to select this directory > automatically thereby avoiding the following prompt. > ======================================================= > Which SSL install path do you want to use? [/usr] > > BUILD INFORMATION > ================================================ > ssl library: OpenSSL 0.9.7a in /usr > ssl header: openssl/ssl.h > libraries: -L/usr/lib -lssl -lcrypto -lgcc > include dir: -I/usr/include -I/usr/kerberos/include > ================================================ > WARNING: AUTHOR takes a string/number not a ARRAY reference. > Please inform the author. > Checking if your kit is complete... > Looks good > Warning: prerequisite LWP::Protocol::https 6.02 not found. We have unknown > version. > Note (probably harmless): No library found for -lgcc > only nested arrays of non-refs are supported at > /usr/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm line 664 > [root@testapache Crypt-SSLeay-0.61_02]# > > I was able to insall Crypt-SSLeay-0.60 from CPAN on the same server

without Show quoted text

> any trouble. Crypt-SSLeay-0.60 Makefile.PL reported the 2 lines:- > > Warning: prerequisite LWP::Protocol::https 6.02 not found. We have unknown > version. > Note (probably harmless): No library found for -lgcc > > But not > > only nested arrays of non-refs are supported at > /usr/lib/perl5/5.8.0/ExtUtils/MakeMaker.pm line 664 > > Best regards > Gordon Camley > > 3rd Line Support > SellerDeck Ltd. > Registered Office (Globe House Lavender Park Road, West Byfleet,

Surrey KT14 Show quoted text

> 6ND) > Company Registration No. 3221222 > VAT no. GB834853604 > > > -----Original Message----- > From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] > Sent: Wednesday, August 01, 2012 5:56 PM > Cc: nanis@cpan.org; gordon.camley@sellerdeck.co.uk > Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck > > <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > > > Hello: > > I am still somewhat unsure about this but I would appreciate it if you > could give the attached version a shot. > > I've uploaded it to CPAN, but it will take about an hour for it to > propagate. > > Thank you. > > -- Sinan > > > On Wed Aug 01 06:32:34 2012, gcamley wrote:

> > As the Sellerdeck developer that discovered the problem I'd like to add > > some background that may assist in deciding whether this is a bug in > > Crypt::SSLeay that needs fixing. > > > > You are correct we do not use Net::SSL via LWP. However we have been > > using Net::SSL for many years without any problems. > > > > The code that failed is unchanged for many years and is simply:- > > > > $ssl_socket->print($sData); > > > > my $buf =''; > > while ($ssl_socket->read($buf, 1024)) > > { > > $sResponse .= $buf; > > } > > > > This worked as the eventually read() returns zero. Now it reads the last > > block of data and the next read causes the script error. > > > > I worked round this by coding the above as:- > > > > $ssl_socket->print($sData); > > > > my $buf =''; > > my ($nBuf) = 1024; > > while ($nBuf == 1024) > > { > > $nBuf = $ssl_socket->read($buf, 1024); > > $sResponse .= $buf; > > } > > > > This will now stop reading if the last block read is shorter than the > > block size. This however will still fail if the last block read is in > > fact equal in size to the buffer. > > > > If there is now a more reliable way of determining when the end of the > > data has been reached then we shall gladly implement it.

> > > >

Wed Aug 01 18:00:58 2012 nanis [...] runu.moc.invalid - Correspondence added

RT-Send-CC:

gordon.camley [...] sellerdeck.co.uk, nanis [...] cpan.org

I forgot to Cc: you. -- Sinan On Wed Aug 01 18:00:11 2012, NANIS wrote: Show quoted text

> Aaaarrrrgggghhhh!!!! > > That had been a long-standing thing -- giving all previous authors > credit. I forgot that I had also done that before fiddling with this. I > should have branched from an earlier commit. Apparently, your > ExtUtils::MakeMaker is rather old. Anyway ... > > Could you just edit Makefile.PL and replace the array ref for AUTHOR in > the WriteMakefile call with a scalar, any scalar? > > I am on a phone call right now, and it might be too late in the UK by > the time I get done. > > -- Sinan

Wed Aug 01 18:16:41 2012 nanis [...] cpan.org - Correspondence added

CC:	gordon.camley [...] sellerdeck.co.uk, "A. Sinan Unur" <sinan [...] unur.com>
Subject:	Re: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck
Date:	Wed, 1 Aug 2012 18:16:31 -0400
To:	bug-Crypt-SSLeay [...] rt.cpan.org
From:	"A. Sinan Unur" <nanis [...] cpan.org>

Hi Gordon: ExtUtils::MakeMaker pre-6.57_02 doesn't handle array of authors. https://github.com/nanis/Crypt-SSLeay/tarball/0.61_03 should allow Makefile.PL to run to completion. Apologies for the inconvenience. -- Sinan On Wed, Aug 1, 2012 at 6:00 PM, A. Sinan Unur via RT <bug-Crypt-SSLeay@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > > > I forgot to Cc: you. > > -- Sinan > > > On Wed Aug 01 18:00:11 2012, NANIS wrote:

>> Aaaarrrrgggghhhh!!!! >> >> That had been a long-standing thing -- giving all previous authors >> credit. I forgot that I had also done that before fiddling with this. I >> should have branched from an earlier commit. Apparently, your >> ExtUtils::MakeMaker is rather old. Anyway ... >> >> Could you just edit Makefile.PL and replace the array ref for AUTHOR in >> the WriteMakefile call with a scalar, any scalar? >> >> I am on a phone call right now, and it might be too late in the UK by >> the time I get done. >> >> -- Sinan

>

-- A. Sinan Unur http://www.unur.com/sinan/

Mon Aug 06 07:28:11 2012 nanis [...] runu.moc.invalid - Correspondence added

RT-Send-CC:

gordon.camley [...] sellerdeck.co.uk, nanis [...] cpan.org

Hello: Crypt-SSLeay 0.64 is on CPAN. I gave up on trying to distinguish between good & bad zero returns from the underlying SSL_read (I think that was misguided anyway). So please give that a whirl. Also, note that I threw away a significant amount of code from Makefile.PL dealing with trying to guess OpenSSL library locations. If the libraries and header files are not in places where your build tools would find them, please add them to the appropriate environment variables (with GCC, CPATH for headers, and LIBRARY_PATH for libs, and make sure LD_LIBRARY_PATH includes the location where shared OpenSSL libs are). Thank you for your feedback. Hope this works for you. -- Sinan

Mon Aug 06 07:28:13 2012 nanis [...] runu.moc.invalid - Status changed from 'open' to 'resolved'

Mon Aug 06 08:22:04 2012 gordon.camley [...] sellerdeck.co.uk - Correspondence added

Subject:	RE: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck
Date:	Mon, 6 Aug 2012 15:21:11 +0300
To:	<bug-Crypt-SSLeay [...] rt.cpan.org>
From:	"Gordon Camley" <gordon.camley [...] sellerdeck.co.uk>

Tried the install from CPAN and got the following which I don't think is down to the library locations (although I may be wrong):- gcc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386 -mcpu=i686 -DVERSION=\"0.64\" -DXS_VERSION=\"0.64\" -fPIC "-I/us r/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" SSLeay.c In file included from /usr/include/openssl/ssl.h:179, from SSLeay.xs:35: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179, from SSLeay.xs:35: /usr/include/openssl/kssl.h:134: parse error before "krb5_enctype" /usr/include/openssl/kssl.h:136: parse error before '*' token /usr/include/openssl/kssl.h:137: parse error before '}' token /usr/include/openssl/kssl.h:149: parse error before "kssl_ctx_setstring" /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:150: parse error before '*' token /usr/include/openssl/kssl.h:151: parse error before '*' token /usr/include/openssl/kssl.h:151: parse error before '*' token /usr/include/openssl/kssl.h:152: parse error before '*' token /usr/include/openssl/kssl.h:153: parse error before "kssl_ctx_setprinc" /usr/include/openssl/kssl.h:153: parse error before '*' token /usr/include/openssl/kssl.h:155: parse error before "kssl_cget_tkt" /usr/include/openssl/kssl.h:155: parse error before '*' token /usr/include/openssl/kssl.h:157: parse error before "kssl_sget_tkt" /usr/include/openssl/kssl.h:157: parse error before '*' token /usr/include/openssl/kssl.h:159: parse error before "kssl_ctx_setkey" /usr/include/openssl/kssl.h:159: parse error before '*' token /usr/include/openssl/kssl.h:161: parse error before "context" /usr/include/openssl/kssl.h:162: parse error before "kssl_build_principal_2" /usr/include/openssl/kssl.h:162: parse error before "context" /usr/include/openssl/kssl.h:165: parse error before "kssl_validate_times" /usr/include/openssl/kssl.h:165: parse error before "atime" /usr/include/openssl/kssl.h:167: parse error before "kssl_check_authent" /usr/include/openssl/kssl.h:167: parse error before '*' token /usr/include/openssl/kssl.h:169: parse error before "enctype" In file included from SSLeay.xs:35: /usr/include/openssl/ssl.h:909: parse error before "KSSL_CTX" /usr/include/openssl/ssl.h:931: parse error before '}' token make: *** [SSLeay.o] Error 1 NANIS/Crypt-SSLeay-0.64.tar.gz /usr/bin/make -- NOT OK Regards Gordon Show quoted text

-----Original Message----- From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] Sent: Monday, August 06, 2012 2:28 PM Cc: gordon.camley@sellerdeck.co.uk; nanis@cpan.org Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > Hello: Crypt-SSLeay 0.64 is on CPAN. I gave up on trying to distinguish between good & bad zero returns from the underlying SSL_read (I think that was misguided anyway). So please give that a whirl. Also, note that I threw away a significant amount of code from Makefile.PL dealing with trying to guess OpenSSL library locations. If the libraries and header files are not in places where your build tools would find them, please add them to the appropriate environment variables (with GCC, CPATH for headers, and LIBRARY_PATH for libs, and make sure LD_LIBRARY_PATH includes the location where shared OpenSSL libs are). Thank you for your feedback. Hope this works for you. -- Sinan

Mon Aug 06 08:22:05 2012 The RT System itself - Status changed from 'resolved' to 'open'

Mon Aug 06 10:28:36 2012 nanis [...] runu.moc.invalid - Correspondence added

RT-Send-CC:

gordon.camley [...] sellerdeck.co.uk, nanis [...] cpan.org

Hi Gordon: Which version of OpenSSL do you have on that system? Could you please check the value in opensslv.h and report? -- Sinan On Mon Aug 06 08:22:04 2012, gcamley wrote: Show quoted text

> Tried the install from CPAN and got the following which I don't think is > down to the library locations (although I may be wrong):- > > gcc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING > -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D > _FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386

-mcpu=i686 Show quoted text

> -DVERSION=\"0.64\" -DXS_VERSION=\"0.64\" -fPIC "-I/us > r/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" SSLeay.c > In file included from /usr/include/openssl/ssl.h:179, > from SSLeay.xs:35: > /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory > In file included from /usr/include/openssl/ssl.h:179, > from SSLeay.xs:35: > /usr/include/openssl/kssl.h:134: parse error before "krb5_enctype" > /usr/include/openssl/kssl.h:136: parse error before '*' token > /usr/include/openssl/kssl.h:137: parse error before '}' token > /usr/include/openssl/kssl.h:149: parse error before "kssl_ctx_setstring" > /usr/include/openssl/kssl.h:149: parse error before '*' token > /usr/include/openssl/kssl.h:150: parse error before '*' token > /usr/include/openssl/kssl.h:151: parse error before '*' token > /usr/include/openssl/kssl.h:151: parse error before '*' token > /usr/include/openssl/kssl.h:152: parse error before '*' token > /usr/include/openssl/kssl.h:153: parse error before "kssl_ctx_setprinc" > /usr/include/openssl/kssl.h:153: parse error before '*' token > /usr/include/openssl/kssl.h:155: parse error before "kssl_cget_tkt" > /usr/include/openssl/kssl.h:155: parse error before '*' token > /usr/include/openssl/kssl.h:157: parse error before "kssl_sget_tkt" > /usr/include/openssl/kssl.h:157: parse error before '*' token > /usr/include/openssl/kssl.h:159: parse error before "kssl_ctx_setkey" > /usr/include/openssl/kssl.h:159: parse error before '*' token > /usr/include/openssl/kssl.h:161: parse error before "context" > /usr/include/openssl/kssl.h:162: parse error before

"kssl_build_principal_2" Show quoted text

> /usr/include/openssl/kssl.h:162: parse error before "context" > /usr/include/openssl/kssl.h:165: parse error before "kssl_validate_times" > /usr/include/openssl/kssl.h:165: parse error before "atime" > /usr/include/openssl/kssl.h:167: parse error before "kssl_check_authent" > /usr/include/openssl/kssl.h:167: parse error before '*' token > /usr/include/openssl/kssl.h:169: parse error before "enctype" > In file included from SSLeay.xs:35: > /usr/include/openssl/ssl.h:909: parse error before "KSSL_CTX" > /usr/include/openssl/ssl.h:931: parse error before '}' token > make: *** [SSLeay.o] Error 1 > NANIS/Crypt-SSLeay-0.64.tar.gz > /usr/bin/make -- NOT OK > > Regards Gordon > > -----Original Message----- > From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] > Sent: Monday, August 06, 2012 2:28 PM > Cc: gordon.camley@sellerdeck.co.uk; nanis@cpan.org > Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck > > <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > > > Hello: > > Crypt-SSLeay 0.64 is on CPAN. I gave up on trying to distinguish between > good & bad zero returns from the underlying SSL_read (I think that was > misguided anyway). So please give that a whirl. > > Also, note that I threw away a significant amount of code from > Makefile.PL dealing with trying to guess OpenSSL library locations. If > the libraries and header files are not in places where your build tools > would find them, please add them to the appropriate environment > variables (with GCC, CPATH for headers, and LIBRARY_PATH for libs, and > make sure LD_LIBRARY_PATH includes the location where shared OpenSSL > libs are). > > Thank you for your feedback. Hope this works for you. > > -- Sinan > > >

Mon Aug 06 11:12:37 2012 gordon.camley [...] sellerdeck.co.uk - Correspondence added

Subject:	RE: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck
Date:	Mon, 6 Aug 2012 18:11:51 +0300
To:	<bug-Crypt-SSLeay [...] rt.cpan.org>
From:	"Gordon Camley" <gordon.camley [...] sellerdeck.co.uk>

Header file says #define OPENSSL_VERSION_TEXT "OpenSSL 0.9.7a Feb 19 2003" - it is on an old internal development server used for testing backwards compatibility. Regards Gordon Show quoted text

-----Original Message----- From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] Sent: Monday, August 06, 2012 5:29 PM Cc: gordon.camley@sellerdeck.co.uk; nanis@cpan.org Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > Hi Gordon: Which version of OpenSSL do you have on that system? Could you please check the value in opensslv.h and report? -- Sinan On Mon Aug 06 08:22:04 2012, gcamley wrote:

> Tried the install from CPAN and got the following which I don't think is > down to the library locations (although I may be wrong):- > > gcc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING > -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D > _FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386

-mcpu=i686

> -DVERSION=\"0.64\" -DXS_VERSION=\"0.64\" -fPIC "-I/us > r/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" SSLeay.c > In file included from /usr/include/openssl/ssl.h:179, > from SSLeay.xs:35: > /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory > In file included from /usr/include/openssl/ssl.h:179, > from SSLeay.xs:35: > /usr/include/openssl/kssl.h:134: parse error before "krb5_enctype" > /usr/include/openssl/kssl.h:136: parse error before '*' token > /usr/include/openssl/kssl.h:137: parse error before '}' token > /usr/include/openssl/kssl.h:149: parse error before "kssl_ctx_setstring" > /usr/include/openssl/kssl.h:149: parse error before '*' token > /usr/include/openssl/kssl.h:150: parse error before '*' token > /usr/include/openssl/kssl.h:151: parse error before '*' token > /usr/include/openssl/kssl.h:151: parse error before '*' token > /usr/include/openssl/kssl.h:152: parse error before '*' token > /usr/include/openssl/kssl.h:153: parse error before "kssl_ctx_setprinc" > /usr/include/openssl/kssl.h:153: parse error before '*' token > /usr/include/openssl/kssl.h:155: parse error before "kssl_cget_tkt" > /usr/include/openssl/kssl.h:155: parse error before '*' token > /usr/include/openssl/kssl.h:157: parse error before "kssl_sget_tkt" > /usr/include/openssl/kssl.h:157: parse error before '*' token > /usr/include/openssl/kssl.h:159: parse error before "kssl_ctx_setkey" > /usr/include/openssl/kssl.h:159: parse error before '*' token > /usr/include/openssl/kssl.h:161: parse error before "context" > /usr/include/openssl/kssl.h:162: parse error before

"kssl_build_principal_2"

> /usr/include/openssl/kssl.h:162: parse error before "context" > /usr/include/openssl/kssl.h:165: parse error before "kssl_validate_times" > /usr/include/openssl/kssl.h:165: parse error before "atime" > /usr/include/openssl/kssl.h:167: parse error before "kssl_check_authent" > /usr/include/openssl/kssl.h:167: parse error before '*' token > /usr/include/openssl/kssl.h:169: parse error before "enctype" > In file included from SSLeay.xs:35: > /usr/include/openssl/ssl.h:909: parse error before "KSSL_CTX" > /usr/include/openssl/ssl.h:931: parse error before '}' token > make: *** [SSLeay.o] Error 1 > NANIS/Crypt-SSLeay-0.64.tar.gz > /usr/bin/make -- NOT OK > > Regards Gordon > > -----Original Message----- > From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] > Sent: Monday, August 06, 2012 2:28 PM > Cc: gordon.camley@sellerdeck.co.uk; nanis@cpan.org > Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck > > <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > > > Hello: > > Crypt-SSLeay 0.64 is on CPAN. I gave up on trying to distinguish between > good & bad zero returns from the underlying SSL_read (I think that was > misguided anyway). So please give that a whirl. > > Also, note that I threw away a significant amount of code from > Makefile.PL dealing with trying to guess OpenSSL library locations. If > the libraries and header files are not in places where your build tools > would find them, please add them to the appropriate environment > variables (with GCC, CPATH for headers, and LIBRARY_PATH for libs, and > make sure LD_LIBRARY_PATH includes the location where shared OpenSSL > libs are). > > Thank you for your feedback. Hope this works for you. > > -- Sinan > > >

Mon Aug 06 11:37:34 2012 nanis [...] runu.moc.invalid - Correspondence added

RT-Send-CC:

gordon.camley [...] sellerdeck.co.uk, nanis [...] cpan.org

It looks like your OpenSSL was built with Kerberos 5 support. See if setting CPATH=/usr/include/krb5:$CPATH before running Makefile.PL helps. Or, maybe check where the Kerberos 5 header file krb5.h is and add that to CPATH. -- Sinan On Mon Aug 06 11:12:37 2012, gcamley wrote: Show quoted text

> Header file says > > #define OPENSSL_VERSION_TEXT "OpenSSL 0.9.7a Feb 19 2003" > > - it is on an old internal development server used for testing backwards > compatibility. > > Regards > Gordon > > -----Original Message----- > From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] > Sent: Monday, August 06, 2012 5:29 PM > Cc: gordon.camley@sellerdeck.co.uk; nanis@cpan.org > Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck > > <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > > > Hi Gordon: > > Which version of OpenSSL do you have on that system? Could you please > check the value in opensslv.h and report? > > -- Sinan > > > On Mon Aug 06 08:22:04 2012, gcamley wrote:

> > Tried the install from CPAN and got the following which I don't think is > > down to the library locations (although I may be wrong):- > > > > gcc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING > > -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D > > _FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386

> -mcpu=i686

> > -DVERSION=\"0.64\" -DXS_VERSION=\"0.64\" -fPIC "-I/us > > r/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" SSLeay.c > > In file included from /usr/include/openssl/ssl.h:179, > > from SSLeay.xs:35: > > /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory

Tue Aug 07 11:40:53 2012 gordon.camley [...] sellerdeck.co.uk - Correspondence added

Subject:	RE: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck
Date:	Tue, 7 Aug 2012 18:40:02 +0300
To:	<bug-Crypt-SSLeay [...] rt.cpan.org>
From:	"Gordon Camley" <gordon.camley [...] sellerdeck.co.uk>

I couldn't get it to build on my old development test server but have tested on another server which successfully auto updated Crypt::SSLeay to version 0.64 and the behaviour is now as it was in version 0.58. Thanks for your prompt attention to this issue. Gordon Camley SellerDeck Ltd. Show quoted text

-----Original Message----- From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] Sent: Monday, August 06, 2012 6:38 PM Cc: gordon.camley@sellerdeck.co.uk; nanis@cpan.org Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > It looks like your OpenSSL was built with Kerberos 5 support. See if setting CPATH=/usr/include/krb5:$CPATH before running Makefile.PL helps. Or, maybe check where the Kerberos 5 header file krb5.h is and add that to CPATH. -- Sinan On Mon Aug 06 11:12:37 2012, gcamley wrote:

> Header file says > > #define OPENSSL_VERSION_TEXT "OpenSSL 0.9.7a Feb 19 2003" > > - it is on an old internal development server used for testing backwards > compatibility. > > Regards > Gordon > > -----Original Message----- > From: A. Sinan Unur via RT [mailto:bug-Crypt-SSLeay@rt.cpan.org] > Sent: Monday, August 06, 2012 5:29 PM > Cc: gordon.camley@sellerdeck.co.uk; nanis@cpan.org > Subject: [rt.cpan.org #78695] Paypal / Actinic / SellerDeck > > <URL: https://rt.cpan.org/Ticket/Display.html?id=78695 > > > Hi Gordon: > > Which version of OpenSSL do you have on that system? Could you please > check the value in opensslv.h and report? > > -- Sinan > > > On Mon Aug 06 08:22:04 2012, gcamley wrote:

> > Tried the install from CPAN and got the following which I don't think is > > down to the library locations (although I may be wrong):- > > > > gcc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING > > -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D > > _FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -march=i386

> -mcpu=i686

> > -DVERSION=\"0.64\" -DXS_VERSION=\"0.64\" -fPIC "-I/us > > r/lib/perl5/5.8.0/i386-linux-thread-multi/CORE" SSLeay.c > > In file included from /usr/include/openssl/ssl.h:179, > > from SSLeay.xs:35: > > /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory

Tue Aug 07 17:00:02 2012 nanis [...] runu.moc.invalid - Correspondence added

RT-Send-CC:

gordon.camley [...] sellerdeck.co.uk, nanis [...] cpan.org

Hi Gordon: Thank you very much for the update. I am going to mark this bug as resolved, and open a new bug for the build issue. My priority right now is to add support for threads and get that building OK in most cases, and then I am going to come back investigate this. I do appreciate the time you spent trying things out. Thank you and good luck. -- Sinan On Tue Aug 07 11:40:53 2012, gcamley wrote: Show quoted text

> I couldn't get it to build on my old development test server but have

tested Show quoted text

> on another server which successfully auto updated Crypt::SSLeay to version > 0.64 and the behaviour is now as it was in version 0.58. > > Thanks for your prompt attention to this issue. > > Gordon Camley > SellerDeck Ltd.

Tue Aug 07 17:00:03 2012 nanis [...] runu.moc.invalid - Status changed from 'open' to 'resolved'