DEBUG1 cipher is different from session_status.ssl_cipher

[robins]

Are there any scenarios where DEBUG1 says cipher is <none> whereas MySQL's performance_schema.session_status shows a non-empty SSL Cipher?

mysqlfdw=> \det+
List of foreign tables
-[ RECORD 1 ]-----------------------------------------------------------
Schema      | public
Table       | ps
Server      | mysql_server
FDW options | (dbname 'performance_schema', table_name 'session_status')
Description |

mysqlfdw=> set client_min_messages=DEBUG1;
SET
mysqlfdw=> select * from ps where variable_name = 'Ssl_cipher';
DEBUG:  Successfully connected to MySQL database performance_schema at server xxxxx via TCP/IP with cipher <none> (server version: 8.0.23, protocol version: 10)
-[ RECORD 1 ]--+----------------------------
variable_name  | Ssl_cipher
variable_value | ECDHE-RSA-AES128-GCM-SHA256

mysqlfdw=> \dx mysql_fdw
List of installed extensions
-[ RECORD 1 ]-------------------------------------------------
Name        | mysql_fdw
Version     | 1.1
Schema      | public
Description | Foreign data wrapper for querying a MySQL server

[surajkharage19]

Hi @robins,

The ssl_cipher value emitted in DEBUG message is nothing but the value provided at foreign server for MySQL connection. If we don't have ssl_cipher value provided then it will just print irrespective of ssl_cipher value on MySQL server. And that is the reason you could see different values.

We will check if we can do something here to print the correct ssl_cipher value after establishing MySQL connection even though we do not provide ssl_cipher at server level. Once MySQL connection is established using mysql_real_connect(), we can check if the connection structure(conn) has loaded with correct ssl_cipher and then use mysql_get_ssl_cipher() to get the same.

[robins]

Okay.. That makes sense... and then its currently working as intended. Obviously it'd be great to have the feature addition (down the line).

Thanks for the clarification.