Hide Forgot
Description of problem: mysql is failing its regression tests in rawhide, apparently because of a change in the reported name of a cipher algorithm; the diffs from expected output look like -Ssl_cipher DHE-RSA-AES256-SHA +Ssl_cipher DHE-RSA-AES256-SHA256 Essentially the same mysql sources built fine two weeks ago in rawhide, and the same SRPM still does build on my F16 workstation, so this seems to be a behavioral change between openssl 1.0.0 and 1.0.1. Is there any chance of getting this reverted? It's going to be a PITA if I have to patch these test results indefinitely (and it will be indefinitely, because mysql upstream prefers their own "yassl" implementation and are unlikely to change it to follow arbitrary changes in openssl). Failed build's logs are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3781178 Last successful build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3738677 Version-Release number of selected component (if applicable): openssl-1.0.1-0.1.beta2.fc17
I should point out that this change is not merely an issue of cosmetic changes in regression test output: it appears to me that it will lead to actual login failures in the field. The reason is that mysql has an account-security option that allows specification of a particular cipher that must be used by connections under that account. One of the failing regression tests demonstrates that after grant select on test.* to ssl_user2@localhost require cipher "DHE-RSA-AES256-SHA"; it is no longer possible for ssl_user2 to log in, whereas that was possible last week. While I could patch this test to specify DHE-RSA-AES256-SHA256 instead, that will not fix any such grants that are out there in production databases.
I poked around in the mysql source code and confirmed that they are storing the REQUIRE CIPHER argument as a simple text string, and strcmp'ing it against the output of SSL_get_cipher(). So renaming of ciphers in that function's output *will* break this application, and I wouldn't be surprised if it causes problems for other apps too. If this change isn't undone, what I will probably do is patch in a translation layer to restore the pre-1.0.1 naming, so as to not break mysql users' security configurations. That's not going to be particularly desirable, though, because mysql will then be permanently out of step with the cipher names seen in other openssl applications.
Tom, the openssl-1.0.1 supports TLS 1.2 and TLS 1.1 with new ciphersuites and hmacs. That means the algorithm used is really different and instead of SHA1 hmac SHA256 hmac is used. I suppose you could patch the tests/code? so that only TLS1.0 is used and these new ciphers and hmacs will not be chosen. But I am not sure it is really desirable.
Hm, so you're saying that the default choice of cipher algorithm is different in 1.0.1 than in previous releases? That's not what I thought was happening, but it would explain the behavior. Is there any way to adjust the choice without changing openssl, ideally via an environment variable or some such?
Yes, exactly. Unfortunately there is no environment variable to change the choice. You have to do it programmatically. Basically by restricting the TLS version to 1.0.
OK, thanks for the info. Not sure what I'll do about this, but it doesn't seem that openssl is doing something unreasonable.