|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68046 5.5.17 breaks mysqlnd + SSL again
Submitted: 2014-09-18 15:42 UTC Modified: 2015-03-04 15:56 UTC
Avg. Score:4.8 ± 0.6
Reproduced:12 of 12 (100.0%)
Same Version:11 (91.7%)
Same OS:10 (83.3%)
From: spam2 at rhsoft dot net Assigned: rdlowrey (profile)
Status: Closed Package: MySQLi related
PHP Version: 5.5.17 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
29 + 47 = ?
Subscribe to this entry?

 [2014-09-18 15:42 UTC] spam2 at rhsoft dot net
after (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?

OK: mail - send - relay


[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
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);


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-09-20 21:56 UTC] spam2 at rhsoft dot net
i bet the report below on the roundcube-list has the same root-cause

likely a side-effect of

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-22 15:07 UTC]
-Assigned To: +Assigned To: rdlowrey
 [2014-09-22 15:07 UTC]
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:

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-22 15:18 UTC] 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:22 UTC]
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:30 UTC] spam2 at rhsoft dot net
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?
mysqli_ssl_set ($link, $key, $cert, $ca, NULL, NULL) runs into a timeout
 [2014-09-22 15:34 UTC]
Please submit a PR if you think you have something useful to contribute to the project instead of trying to push it off on other people. Complaining is being part of the problem. Contributing is being part of the solution. Thanks for your time.
 [2014-09-22 15:42 UTC] spam2 at rhsoft dot net
> Complaining is being part of the problem
> Contributing is being part of the solution

oh yeah the next time i don't open a bugreport, just delete the new built RPM and go my way because i can't offer a auto-test matching the upstream codebase but is not much more than a one liner

i hestitate to express what i really think about such respones
 [2014-09-22 15:43 UTC]
One line fixes are super easy to PR.
 [2014-09-22 15:56 UTC] spam2 at rhsoft dot net
boah read what i write - *the test* is practically a one-liner, not the fix and i would have expected after mysqlnd with ssl was broken 3 years ago that won't happen again upstream and catched by tests

guess why i wrote one matching my infrastructure at that time

the reason why i complain is that when in software-development the same bug makes it twice in a stable release something goes terrible wrong and given we have now 2014 (one year after Snowden) it's not that uncommon to necrypt MySQL connections
 [2014-09-26 10:24 UTC] alistair dot prestidge at gmail dot com
Any I idea when 5.5.18 will be release to fix this issue please?
 [2014-09-26 10:29 UTC] spam2 at rhsoft dot net
interesting question - if it would be the linux kernel it would already have been released by the "if it breaks revert it"-policy.....
 [2014-10-01 10:02 UTC] alistair dot prestidge at gmail dot com
So do I have to live with a broken version of PHP or will we get 5.5.18 any time soon?
 [2014-10-01 17:05 UTC] bugs dot php dot net at numlock dot ch
Looking forward to 5.5.18 and 5.4.34 fixing this bug as it basically breaks encrypted (SSL) communication to a MySQL server. Thanks.
 [2014-10-05 23:59 UTC] spam2 at rhsoft dot net
are you developers right in your brain to still offer the broken 5.5.17 on the download page? you can't seriously break SSL left and right in 2014 and don't care for weeks

it just don't matter what it was supposed to fixed

that breakage is unacceptable and has to be reverted immediately after realize the breakage or fixed properly - either way: leave a broken release knowingly on the download page is irresponsible without any excuse
 [2014-10-13 08:07 UTC] alistair dot prestidge at gmail dot com
Hi any news on a live fix for this? Is 5.5.18 any time soon?
 [2014-10-15 09:18 UTC] alistair dot prestidge at gmail dot com
 [2014-10-15 09:23 UTC]
What is keeping you to roll back to 5.5.16?
5.5.17 was not a security release.
 [2014-10-15 09:37 UTC] spam2 at rhsoft dot net
what is keeping you to rollback and remove the download link for 5.5.17 so that not everybody needs to find out the hard way it is broken? it is just stupidity at it's best place a known broken download on the homepage over weeks

i never rolled out 5.5.17 because i test my deployments before
 [2014-10-15 11:17 UTC] elmex7 at gmail dot com
"What is keeping you to roll back to 5.5.16?"

This is the behaviour, that makes one change from php to other languages.

In the future, please test your software at least basically before deploying it widely, thanks!
 [2014-10-15 12:54 UTC] alistair dot prestidge at gmail dot com
So I am not allowed the other bug fixes on 5.5.17 is that what you are saying?

I have not put this into production but I would really like to.
 [2014-10-15 13:10 UTC]
There are people who are keen on a timely bugfix (this is absolutely ok) and there are people who prefer name calling over contributing (which surprisingly  doesn't encourage enthusiasm).
 [2014-10-15 13:16 UTC] spam2 at rhsoft dot net
which enthusiasm?

enthusiasm would have been release 5.5.18 on 2014-09-19 with all bugfixes of 5.5.17 excluding the one breaking SSL
 [2014-10-15 13:52 UTC]
> So I am not allowed the other bug fixes on 5.5.17 is that what you are saying?

Just remember for a minute that each release takes ton of donated time from people willing to contribute to the project, all you're contributing by spamming this bug report is noise.

You know where to get the source code, if you ever feel _one_ bug is a show stopper, feel free to grab the tag from git, revert the offending commit(s) and compile your own package so you _can_  benefit from all of the other bug fixes.

But since you've waited so long without doing that, you could just go and grab and build that instead.
 [2014-10-15 14:12 UTC]
5.5.18 (and 5.4.34) should be released fixing this issue.
thanks for your patience!
(I will try to find time to extend our ext/mysqli/tests/mysqli_ssl_set.phpt test and make sure that our travis environment supports properly testing ssl connections to mysql, but feel free send a PR if you are willing to help out)
 [2014-10-15 15:24 UTC] alistair dot prestidge at gmail dot com
Brilliant thank you very much tyrael. Very much appreciated.

Just to clear up a few things I was really not trying to annoy anyone here. I was however feeling very frustrated that no one was replying to anybodies questions about when this fix would be public. Hence why I felt I needed to "spam" the bug report in order to get any sort of answers from any one.

Again I would like to say a big thank you for getting 5.5.18 and 5.4.34  released and I would like to apologise if my "spamming" came across in any way rude or unhelpful.
 [2014-10-15 15:43 UTC]
duh, I missed out the most important part from my previous message:
5.5.18 and 5.4.34 planned to be released on this thursday.

btw. if anybody feels that there a bug is not getting enough attention, feel free to drop an email to the internals@ mailing list or poke the RMs for the affected version(for 5.4 it is Stas, for 5.5 that is Julien and for issues with 5.6 you should contact me).
usually that helps more than posting some passive-aggressive/rude comments to the bugreport(not pointing fingers, but that is a common thing when reporters feel ignored).
 [2015-03-04 15:56 UTC]
-Status: Assigned +Status: Closed
 [2015-03-04 15:56 UTC]
Although this issue was resolved by reverting the problem commits I want to note that new updates have been pushed upstream to resolve the original bug that the (reverted) problematic commits were attempting to fix:;a=commitdiff;h=fd4641696cc67fedf494717b5e4d452019f04d6f;a=commitdiff;h=1482ed2d5660c3875add40706a18fe29e2b3ff70;a=commitdiff;h=dddbe0fc338a0f01ba336e84755694fb9bfbeb53

Please post a new report if similar behavior is observed going forward (it shouldn't be).
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 17 15:01:31 2024 UTC