-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I believe it's safe to question source code provided with the PHP
source distributions in an attempt to ascertain a possible direction
to take if any might be required.
I've been trying to determine if the mysql module provided with the
PHP source distributions supports ssl connections with conflicting
results/opinions?
I see that the mysqli extension is essentially a wrapper and it
obtains the required libraries from the mysql_config script so if
mysql is built with ssl support the mysqli module will include this
library and theoretically should work with ssl connections.
My question though is related to the mysql module itself which
doesn't have any ARGS for ssl support or a method to automatically
retrieve dependant libraries and is more of a client so before
submitting a feature request , writing a proof of concept or working
on code for a capability that might already exists but is
undocumented, I thought I'd ask first.
- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG31Ly0hzWbkf0eKgRAvTwAJ9on2eJ7Xn5zrKeKRbEK9IrgZPgGQCgwh+Q
FUHi2cd7NRz2G+STBLe3ZJE=
=giiW
-----END PGP SIGNATURE
It is documented at php.net/mysql in the section on connection constants:
MYSQL_CLIENT_SSL
Use SSL encryption. This flag is only available with version 4.x of the
MySQL client library or newer. Version 3.23.x is bundled both with PHP 4
and Windows binaries of PHP 5.
-Rasmus
BuildSmart wrote:
I believe it's safe to question source code provided with the PHP source
distributions in an attempt to ascertain a possible direction to take if
any might be required.I've been trying to determine if the mysql module provided with the PHP
source distributions supports ssl connections with conflicting
results/opinions?I see that the mysqli extension is essentially a wrapper and it obtains
the required libraries from the mysql_config script so if mysql is built
with ssl support the mysqli module will include this library and
theoretically should work with ssl connections.My question though is related to the mysql module itself which doesn't
have any ARGS for ssl support or a method to automatically retrieve
dependant libraries and is more of a client so before submitting a
feature request , writing a proof of concept or working on code for a
capability that might already exists but is undocumented, I thought I'd
ask first.-- Dale
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It is documented at php.net/mysql in the section on connection
constants:MYSQL_CLIENT_SSL
I found this but it didn't provide all the answers to the mysql-ssl
so I asked someone who tried to build PHP with MySQL-SSL but had no
luck making it work about build conditions and build errors and got
remnants of configured source tree from an attempt that failed to
provide a working solution.
Use SSL encryption. This flag is only available with version 4.x of
the
MySQL client library or newer. Version 3.23.x is bundled both with
PHP 4
and Windows binaries of PHP 5.
While waiting for a response I decided to do some testing based on
the build information of the failing build which was chalked up as
something they must have done wrong because they experienced no
issues when using someone elses provided binaries who built it and it
worked.
The only differences I could find was that openssl was enabled in the
working builds but not enabled in the failing build.
As a test I built PHP without openssl and with GD, MySQL (against
mysql-5.0.45 with SSL support) and ZLIB, what I found was unless
openssl is enabled it fails and crashes apache with symbols related
to ssl not found when attempting to perform an SSL connection.
I went a step further and manually added the ssl libraries (-lssl -
lcrypto) to the Makefile (both as bundled and shared) and all worked
well.
This cannot be considered a bug (or maybe it is), perhaps an
additional check could/should be performed to see if mysql is built
with SSL support and if so check whether openssl is enabled and add
the ssl libraries to the sapi build or to MYSQL_SHARED_LDADD if it's
not or to auto-enable openssl?
If this is the suggested approach, I have no objection to doing the
preliminary work and attempt to provide an acceptable solution in
compliance with the existing bug/feature policies.
If it's believed that it's unnecessary because openssl is usually
embedded or loaded at runtime then perhaps amending the documentation
to include information if mysql is built with SSL support and you
wish to use SSL with mysql then it is recommended that openssl also
be enabled?
What do you think?
-Rasmus
BuildSmart wrote:
I believe it's safe to question source code provided with the PHP
source
distributions in an attempt to ascertain a possible direction to
take if
any might be required.I've been trying to determine if the mysql module provided with
the PHP
source distributions supports ssl connections with conflicting
results/opinions?I see that the mysqli extension is essentially a wrapper and it
obtains
the required libraries from the mysql_config script so if mysql is
built
with ssl support the mysqli module will include this library and
theoretically should work with ssl connections.My question though is related to the mysql module itself which
doesn't
have any ARGS for ssl support or a method to automatically retrieve
dependant libraries and is more of a client so before submitting a
feature request , writing a proof of concept or working on code for a
capability that might already exists but is undocumented, I
thought I'd
ask first.-- Dale
- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG34FV0hzWbkf0eKgRAkyBAJ9EPFuhHoM/NeRQyD3O0RV2ZMVRfwCcCACE
2Hw4F+hbbWI9HyVp/X53Tz8=
=H+wS
-----END PGP SIGNATURE
BuildSmart wrote:
The only differences I could find was that openssl was enabled in the
working builds but not enabled in the failing build.
[...]
I went a step further and manually added the ssl libraries (-lssl
-lcrypto) to the Makefile (both as bundled and shared) and all worked well.This cannot be considered a bug (or maybe it is), perhaps an additional
check could/should be performed to see if mysql is built with SSL
support and if so check whether openssl is enabled and add the ssl
libraries to the sapi build or to MYSQL_SHARED_LDADD if it's not or to
auto-enable openssl?
yes, ext/mysql is not too clever about this and simply relies
on ext/openssl being enabled at the same time.
Adding an extra test can't rely on mysql_config though as AFAIR
it is not using mysql_config at all.
If you want to check whether you'd need to add a compile/link
test with a small example program that tries to e.g. use
http://dev.mysql.com/doc/refman/4.1/en/mysql-ssl-set.html
I'm not sure though whether this function is only available
with ssl-enabled MySQL builds or whether it is always there
and just returning error codes, i think it is the later so
you'd have to create a functionality test, not just a simple
"does it compile and link without errors" one.
As this is not a change to the actual functionality of ext/mysql
i think a working patch would be accepted even though the
extension is deprecated by now. OTOH i don't really think it
is worth the effort anymore though ...
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
BuildSmart wrote:
The only differences I could find was that openssl was enabled in
the working builds but not enabled in the failing build.
[...]
I went a step further and manually added the ssl libraries (-lssl -
lcrypto) to the Makefile (both as bundled and shared) and all
worked well.
This cannot be considered a bug (or maybe it is), perhaps an
additional check could/should be performed to see if mysql is
built with SSL support and if so check whether openssl is enabled
and add the ssl libraries to the sapi build or to
MYSQL_SHARED_LDADD if it's not or to auto-enable openssl?yes, ext/mysql is not too clever about this and simply relies
on ext/openssl being enabled at the same time.Adding an extra test can't rely on mysql_config though as AFAIR
it is not using mysql_config at all.If you want to check whether you'd need to add a compile/link
test with a small example program that tries to e.g. use
my current test was to change it to use mysql_config to retrieve the
library details which seemed to work.
http://dev.mysql.com/doc/refman/4.1/en/mysql-ssl-set.html
I'm not sure though whether this function is only available
with ssl-enabled MySQL builds or whether it is always there
and just returning error codes, i think it is the later so
you'd have to create a functionality test, not just a simple
"does it compile and link without errors" one.
Based on your suggestion I tested this and sure enough, simple
compiling tests are inconclusive because it returns 0 even when ssl
is not available in mysql5 and a test of anything less than a valid
mysql ssl connection seems to be inadequate (or I haven't located/
performed the correct test yet).
In mysql4 (4.1.10 and 4.1.13) it doesn't seem to initialize the ssl
library automatically (or properly) and ext/mysql doesn't call
mysql_ssl_set so while a connection can be established, I couldn't
execute any queries successfully or retrieve any server info (just
query failures).
As this is not a change to the actual functionality of ext/mysql
i think a working patch would be accepted even though the
extension is deprecated by now. OTOH i don't really think it
is worth the effort anymore though ...
If it's been EOL'd or NLS'd then working on it doesn't make for a
sound decision and my time would be better spent learning how to
replace mysql calls with mysqli calls if mysqli has been proven to
work properly with mysql-ssl connections.
--
Hartmut Holzgraefe, Principal Support Engineer
- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG38iP0hzWbkf0eKgRAvBCAJ9p84pkizvy/toQW/QgKk0p+fdN2gCeJ91Y
rKwGtxetE+Tt5UDD155mWC8=
=uqIR
-----END PGP SIGNATURE
BuildSmart wrote:
my current test was to change it to use mysql_config to retrieve the
library details which seemed to work.
Does that work all the way back to MySQL 3.23.x?
It is important that ext/mysql stays compatible with
3.23 and 4.0 as these client library versions are not
supported by ext/mysqli ...
If it's been EOL'd or NLS'd then working on it doesn't make for a sound
decision and my time would be better spent learning how to replace mysql
calls with mysqli calls if mysqli has been proven to work properly with
mysql-ssl connections.
if you stay with the procedural interface then it comes
down to 'just' always putting in the database handle
as first parameter instead of doing so optionally as
last parameter only ...
See also http://forge.mysql.com/wiki/Converting_to_MySQLi
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
Rasmus Lerdorf wrote:
It is documented at php.net/mysql in the section on connection constants:
MYSQL_CLIENT_SSL
Use SSL encryption. This flag is only available with version 4.x of the
MySQL client library or newer. Version 3.23.x is bundled both with PHP 4
and Windows binaries of PHP 5.
Hartmut Holzgraefe wrote:
ext/mysql development has been discontinued in favor of ext/mysqli,
one of the goals was to integrate support for exactly SSL and the
other new connection options like gzip compressed connections that
are available as of MySQL 4.1.
Rasmus is right and Hartmut is wrong ... :(
I'd still recommend not to bother with ext/mysql for SSL
though as control over SSL options is indeed available
in ext/mysqli only by mysqli_ssl_set()
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
BuildSmart wrote:
I see that the mysqli extension is essentially a wrapper and it obtains
the required libraries from the mysql_config script so if mysql is built
with ssl support the mysqli module will include this library and
theoretically should work with ssl connections.My question though is related to the mysql module itself which doesn't
have any ARGS for ssl support or a method to automatically retrieve
dependant libraries and is more of a client
When talking about "the mysql module" itself you're talking about
ext/mysql, right?
ext/mysql development has been discontinued in favor of ext/mysqli,
one of the goals was to integrate support for exactly SSL and the
other new connection options like gzip compressed connections that
are available as of MySQL 4.1.
See also http://php.net/mysql:
Although this MySQL extension is compatible with MySQL 4.1.0
and greater, it doesn't support the extra functionality that
these versions provide. For that, use the MySQLi extension.
By that time the codebase of ext/mysql had become a bit of a mess.
It was one of the first PHP extensions ever and there were a few
design decisions made back then that made it almost impossible to
add new features to the existing functions (e.g. the db handle
being an optional parameter at the end of most functions
argument list made it impractical to add any further parameters).
The code was also full of conditional compile branches as it
supported mysql client libraries back to at least MySQL 3.23.
so before submitting a
feature request , writing a proof of concept or working on code for a
capability that might already exists but is undocumented, I thought I'd
ask first.
It doesn't really make sense to add a feature request for a
deprecated extension. All further development effort will
go into ext/mysqli only.
I just checked the manual pages for ext/mysql and ext/mysqli
and found that we're not really making this clear in the
documentation, i'll bring this up with the ext/mysqli maintainers
today and we'll have http://php.net/mysql be more explicit
about this.
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140