Bug #61827 openssl_1 regression test fails when mysql is built with OpenSSL
Submitted: 11 Jul 2011 20:25 Modified: 17 Jul 2013 12:44
Reporter: [ name withheld ] Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: Tests Severity:S3 (Non-critical)
Version:5.5.14, 5.5.15 OS:Any
Assigned to: CPU Architecture:Any
Triage: Needs Triage: D2 (Serious)

[11 Jul 2011 20:25] [ name withheld ]
Description:
As of 5.5.14, mysql no longer passes its regression tests when built with OpenSSL instead of yaSSL.  This appears to be a consequence of the fix for bug #21287, which was a good thing in itself, but the test design fails to account for the possibility that the two versions of the SSL code might produce different error strings.  And in fact I get this:

$ diff r/openssl_1.result r/openssl_1.reject
47,49c47,49
< mysqltest: Could not open connection 'default': 2026 SSL connection error: ASN: bad other signature confirmation
< mysqltest: Could not open connection 'default': 2026 SSL connection error: ASN: bad other signature confirmation
< mysqltest: Could not open connection 'default': 2026 SSL connection error: ASN: bad other signature confirmation
---
> mysqltest: Could not open connection 'default': 2026 SSL connection error: error:00000001:lib(0):func(0):reason(1)
> mysqltest: Could not open connection 'default': 2026 SSL connection error: error:00000001:lib(0):func(0):reason(1)
> mysqltest: Could not open connection 'default': 2026 SSL connection error: error:00000001:lib(0):func(0):reason(1)

The other SSL error messages do match, but not this one.

How to repeat:
1. Build using -DWITH_SSL=system

2. Run regression tests with --ssl option.

I tested against Fedora 13's openssl-1.0.0d-1.fc13, but probably similar things will occur with other versions of OpenSSL.

Suggested fix:
There's probably no good way to ensure that the strings always match.  Maybe need two different versions of the expected results?

Another possibility is to handle this specific case in a way that doesn't depend on the underlying SSL code's message.  Since both current messages are really pretty useless from the user's standpoint, that might be the most user-friendly way forward.
[11 Jul 2011 20:44] Davi Arnaut
Actually, there seems to be two problems. One is that the strings might not match. Second problem seems to be that the code fails to get the relevant error upon SSL_ERROR_SSL, leading to the nonsensical error message.
[12 Jul 2011 12:54] Sveta Smirnova
Thank you for the report.

Verified as described using 5.5 from bzr
[17 Jul 2013 12:44] Erlend Dahl
Fixed in 5.1.66, 5.5.28, 5.6.7, 5.7.0 as a duplicate of bug#62743.