Bug #68046 [Asn]: 5.5.17 breaks mysqlnd + SSL again

From: Date: Mon, 22 Sep 2014 15:30:45 +0000
Subject: Bug #68046 [Asn]: 5.5.17 breaks mysqlnd + SSL again
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-187655@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=68046&edit=1 ID: 68046 User updated by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: 5.5.17 breaks mysqlnd + SSL again Status: Assigned Type: Bug Package: MySQLi related Operating System: Linux PHP Version: 5.5.17 Assigned To: rdlowrey Block user comment: N Private report: N New Comment: how often do i need to post how to test this? what do you do with a pull-request of a code using our own rwapper around mysqli? http://php.net/manual/de/mysqli.ssl-set.php mysqli_ssl_set ($link, $key, $cert, $ca, NULL, NULL) runs into a timeout Previous Comments: ------------------------------------------------------------------------ [2014-09-22 15:22:51] rdlowrey@php.net This is actually not a mysqli issue -- it's an openssl streams issue and has to do with feof() never reporting as true when it should (which causes the script to hang indefinitely). However, any test cases you feel would help can certainly be added. Please submit pull requests via the git account and I will happily merge them. ------------------------------------------------------------------------ [2014-09-22 15:18:06] spam2 at rhsoft dot net there is a simple test i wrote years ago when it was broken the first time * just create certificates * configure mysqld with them * the $this below is only a wrapper which can switch layers * ssl_set() is just the native function $this->ssl_key = '/etc/mysql-ssl/client.pem'; $this->ssl_crt = '/etc/mysql-ssl/client.pem'; $this->ssl_ca = '/etc/mysql-ssl/ca.crt'; $this->conn->ssl_set($this->ssl_key, $this->ssl_crt, $this->ssl_ca, NULL, NULL); ------------------------------------------------------------------------ [2014-09-22 15:07:56] rdlowrey@php.net Yes, we know about this. It was addressed on the mailing list within a couple of hours of the 5.5.17 and 5.4.33 releases. People *do* care about a regression like this. This issue results from trying to fix the DoS vulnerability here: https://bugs.php.net/bug.php?id=41631 Part of the problem is that the streams API has exactly zero test cases and the openssl streams have very few. So when we try to fix one bug there is always the potential to cause another that isn't prevented by preexisting tests. There are volunteers working to improve these aspects of the php-src codebase to help avoid these issues going forward, but it just takes time. ------------------------------------------------------------------------ [2014-09-20 21:56:41] spam2 at rhsoft dot net i bet the report below on the roundcube-list has the same root-cause likely a side-effect of https://bugs.php.net/bug.php?id=41631 what is that difficult to write a simple script connection to mysql over TCP with SSL and run it before propose a release and why does nobody care about such a major regression? _____________________________________________________ My setup: roundcube-1.0.2 + nginx-1.6.2 in a FreeBSD-10 jail. RC will connect to a recent dovecot server in another jail at the same host. Recently, after upgrading php from 5.4.32 to 5.4.33 roundcube will refuse to connect to dovecot: | roundcube: PHP Warning: fgets(): SSL read operation timed out in \ | /...path2rc.../roundcube/program/lib/Roundcube/rcube_imap_generic.php on line 200 Recompiling every port involved and restarting both involved jails hasn't been successful. Only, reverting back to php 5.4.32 made RC work again. Is anyone running into this as well? Any idea how to debug this? _____________________________________________________ ------------------------------------------------------------------------ [2014-09-18 15:42:54] spam2 at rhsoft dot net Description: ------------ after https://bugs.php.net/bug.php?id=55283 (comment from 2011-08-18 01:34 UTC) and 5.3.7 i created a autotest, well with 5.5.17 it is hanging again forever and a clone of the machine with 5.5.16 works still fine what about a autotest in the QA to prevent the same as on 2011-08-18 happen 3 years later? /Volumes/dune/buildserver/autotest/parts/mailrelay.php OK: mail - send - relay /Volumes/dune/buildserver/autotest/parts/mysql_ssl.php ..................... ________________________________________________ [root@buildserver:~]$ ps aux | grep /Volumes/dune/buildserver/autotest/parts/mysql_ssl.php | grep -v grep root 25967 0.0 1.1 322328 34340 pts/2 S<+ 17:24 0:00 /usr/bin/php /Volumes/dune/buildserver/autotest/parts/mysql_ssl.php [root@buildserver:~]$ date Do 18. Sep 17:37:54 CEST 2014 ________________________________________________ [root@backup-buildserver:~]$ php -v PHP 5.5.16 (cli) (built: Aug 22 2014 06:07:26) [root@backup-buildserver:~]$ autotest.php mysql_ssl /Volumes/dune/buildserver/autotest/parts/mysql_ssl.php OK: mysql-over-ssl - DHE-RSA-AES128-SHA / TLSv1 ________________________________________________ mysqli with mysqlnd $this->ssl_key = '/etc/mysql-ssl/client.pem'; $this->ssl_crt = '/etc/mysql-ssl/client.pem'; $this->ssl_ca = '/etc/mysql-ssl/ca.crt'; $>conn->ssl_set($this->ssl_key, $this->ssl_crt, $this->ssl_ca, NULL, NULL); ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=68046&edit=1

« previous php.bugs (#187655) next »