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?
_____________________________________________________

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.

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

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.

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

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.

> 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

One line fixes are super easy to PR.

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

Any I idea when 5.5.18 will be release to fix this issue please?

interesting question - if it would be the linux kernel it would already have been released by the "if it breaks revert it"-policy.....

So do I have to live with a broken version of PHP or will we get 5.5.18 any time soon?

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.

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

Hi any news on a live fix for this? Is 5.5.18 any time soon?

bump*

What is keeping you to roll back to 5.5.16?
5.5.17 was not a security release.

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

"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!

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.

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).

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

> 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 https://github.com/php/php-src/tree/PHP-5.5.18 and build that instead.

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)

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.

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).

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:

http://git.php.net/?p=php-src.git;a=commitdiff;h=fd4641696cc67fedf494717b5e4d452019f04d6f
http://git.php.net/?p=php-src.git;a=commitdiff;h=1482ed2d5660c3875add40706a18fe29e2b3ff70
http://git.php.net/?p=php-src.git;a=commitdiff;h=dddbe0fc338a0f01ba336e84755694fb9bfbeb53

Please post a new report if similar behavior is observed going forward (it shouldn't be).