php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22441 SSL and cURL SSL break with pfpro
Submitted: 2003-02-26 10:30 UTC Modified: 2003-03-09 19:15 UTC
From: eric at vlender dot com Assigned:
Status: No Feedback Package: OpenSSL related
PHP Version: 4.3.1 OS: GNU/Linux (slackware)
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: eric at vlender dot com
New email:
PHP Version: OS:

 

 [2003-02-26 10:30 UTC] eric at vlender dot com
php-4.3.1 / apache 1.3.27 / openssl-0.9.6g / curl-7.10.2
When ever I use the --with-pfpro configure option to compile in payflow pro support, it breaks the cURL (--with-curl) SSL connectability, as well as fsockopen(ssl://somehost.hst)(--with-openssl=/usr/local/ssl) functionality.  

If I recompile with out the payflow-pro extension I can use curl_init(); and fsockopen(ssl:) again.   It took me quite awhile to figure this one out, since curl_init() and fsockopen(ssl:) don't return any errors when --pfpro is compiled in.  They just do not work at all.  No errors, no initalization, nothing.   

Thanks for your time.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-26 10:36 UTC] sniper@php.net
You most likely have too old version of the pfpro SDK.
(old ones have some ssl funcs in it which clash with openssl)

 [2003-02-26 11:12 UTC] eric at vlender dot com
I don't think that is the case.  I am using the following shared library from the sdk:
-rwxrwxr-x    1 501      501        690560 Jun 11  2002 libpfpro.so*

I went and redownloaded the SDK this morning, and the lib in their download is the same as this one.  Here are my configure statements.  (Also, in the meantime I have upgraded to openssl-0.9.7)

apache-1.3.27:  ./configure --prefix=/usr/local/apache --server-uid=daemon --server-gid=daemon --activate-module=src/modules/php4/libphp4.a:

php-4.3.1: ./configure --with-apache=../apache_1.3.27 --enable-bcmath --with-curl --with-gettext --with-mysql=/usr/local/mysql --with-mcrypt=../libmcrypt-2.5.0 --with-openssl=/usr/local/ssl --with-pear --disable-cgi --with-gd --with-zlib --with-jpeg-dir=/usr/lib --with-pfpro

With just the --with-pfpro  option I believe it uses the PHP internal pfpro extension, is this the issue, and should I be pointing it to the pfpro shared library instead?  

If so, will I need to recompile everything as shared?  I prefer static for the raw performance, but will switch to shared if that will solve this issue.

Thanks again.
 [2003-02-26 11:19 UTC] eric at vlender dot com
One other note that I realized should probally be taken into account with this.  I am using apache-ssl Ben-SSL/1.48 and not mod_ssl.
 [2003-02-26 11:25 UTC] sniper@php.net
Where are the pfpro libs and headers installed then?
And you're absolutely sure you don't have any older versions
laying around? (I somewhat remember there being some problems before with pfpro and openssl..)

 [2003-02-26 11:37 UTC] eric at vlender dot com
On a quick side note, Payflow pro is working perfectly.  We use it for our signups, and the signup procedure is functioning perfectly.  Just cURL and fsockopen() are not happy..  :(

I placed them in /usr/lib and /usr/local/include respectfully.  /usr/local/lib/pfpro.h is a symlink to the header in /usr/local/include

~> locate pfpro | sort
/usr/lib/libpfpro.so
/usr/local/include/pfpro.h
/usr/local/lib/pfpro.h
/usr/local/src/php-4.3.1/ext/pfpro
/usr/local/src/php-4.3.1/ext/pfpro/CREDITS
/usr/local/src/php-4.3.1/ext/pfpro/TODO
/usr/local/src/php-4.3.1/ext/pfpro/config.m4
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.c
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.lo
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.o
/usr/local/src/php-4.3.1/ext/pfpro/php_pfpro.h
/usr/local/src/php-4.3.1/tests/testpfpro.php
 [2003-02-28 19:19 UTC] eric at vlender dot com
Well, I have now compiled in openssl-0.9.7a and cURL-7.10.3 and instead of just getting nothing, I get this in my logs:
[Fri Feb 28 18:19:46 2003] [notice] child pid 11916 exit signal Segmentation fault (11)
[Fri Feb 28 18:19:46 2003] [notice] child pid 11908 exit signal Segmentation fault (11)

That is with an attempted fsockopen("ssl://securehost.hre", 443, errorno, error);  call that works perfectly with out the -pfpro option ... 

I guess I can always have PHP shell out to a PERL script and manage the transaction .. 

Thanks for your help :)
 [2003-03-04 20:11 UTC] sniper@php.net
Does compiling PHP as DSO for Apache fix this?
If so, you can bogus this, we already have a report about that one.


 [2003-03-09 19:15 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2003-08-05 10:38 UTC] bduell at ncacasi dot org
I have verified, through VeriSign, that the SDK of PayflowPro (currently, v. 3.06) is statically linked against the openssl libraries.

They have no plans on changing this design, therefor we will be changing payment processors.

Good luck!
 [2007-10-29 21:00 UTC] jvinet at zeroflux dot org
I've had the same problem with the old/deprecated pfpro sdk and PHP 4.4.7.

When the extension is built into the php binary (--with-pfpro=DIR), cURL breaks with https:// URLs.

When the extension is built as a shared module (--with-pfpro=shared,DIR), cURL works.

Hope this helps, though in the long run, I'd recommend moving away from any reliance on the pfpro SDK.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 05 02:01:30 2024 UTC