Description:
During remote Clone recovery, Group Replication copies its recovery TLS paths to
the Clone plugin by constructing internal SQL. The values are appended between
apostrophes without SQL-literal escaping:
```cpp
std::string q = " SET GLOBAL clone_ssl_ca = '";
q.append(ssl_ca);
q.append("'");
```
The same pattern is used for `clone_ssl_cert` and `clone_ssl_key`. A path that is
valid as a Group Replication sysvar value but contains an apostrophe therefore
turns into invalid internal SQL and prevents Clone recovery before cloning starts.
How to repeat:
The parser/configuration boundary is reproducible on stock MySQL 8.4.11:
```sql
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
INSTALL PLUGIN clone SONAME 'mysql_clone.so';
SET GLOBAL group_replication_recovery_ssl_ca = '/tmp/ca''quoted.pem';
SELECT @@global.group_replication_recovery_ssl_ca;
SET GLOBAL clone_ssl_ca = '/tmp/ca.pem';
SELECT @@global.clone_ssl_ca;
```
The first query succeeds and returns `/tmp/ca'quoted.pem`; the normal Clone
control also succeeds. Now execute the exact SQL text generated by
`Remote_clone_handler::set_clone_ssl_options()` for that stored value:
```sql
SET GLOBAL clone_ssl_ca = '/tmp/ca'quoted.pem';
```
Observed result:
```text
ERROR 1064 (42000): You have an error in your SQL syntax
```
`SELECT 1` succeeds afterward; this is a recovery-setup failure, not a server
crash. In a full three-member test, configure the same CA/certificate/key path
on a joining member and force distributed recovery to select Clone.
Actual result
MySQL 8.4.11 accepts and stores the apostrophe-bearing GR recovery path. The
unescaped SQL generated from that value fails parsing with error 1064. The full
GR-to-Clone transition was not executed in the available single-node setup.
Expected result
All path values accepted by Group Replication should be transferred to Clone
without changing SQL syntax. The joining member should either begin Clone or
fail later for an actual file/TLS reason, not because generated SQL is invalid.
© 2026, Oracle Corporation and/or its affiliates
Description: During remote Clone recovery, Group Replication copies its recovery TLS paths to the Clone plugin by constructing internal SQL. The values are appended between apostrophes without SQL-literal escaping: ```cpp std::string q = " SET GLOBAL clone_ssl_ca = '"; q.append(ssl_ca); q.append("'"); ``` The same pattern is used for `clone_ssl_cert` and `clone_ssl_key`. A path that is valid as a Group Replication sysvar value but contains an apostrophe therefore turns into invalid internal SQL and prevents Clone recovery before cloning starts. How to repeat: The parser/configuration boundary is reproducible on stock MySQL 8.4.11: ```sql INSTALL PLUGIN group_replication SONAME 'group_replication.so'; INSTALL PLUGIN clone SONAME 'mysql_clone.so'; SET GLOBAL group_replication_recovery_ssl_ca = '/tmp/ca''quoted.pem'; SELECT @@global.group_replication_recovery_ssl_ca; SET GLOBAL clone_ssl_ca = '/tmp/ca.pem'; SELECT @@global.clone_ssl_ca; ``` The first query succeeds and returns `/tmp/ca'quoted.pem`; the normal Clone control also succeeds. Now execute the exact SQL text generated by `Remote_clone_handler::set_clone_ssl_options()` for that stored value: ```sql SET GLOBAL clone_ssl_ca = '/tmp/ca'quoted.pem'; ``` Observed result: ```text ERROR 1064 (42000): You have an error in your SQL syntax ``` `SELECT 1` succeeds afterward; this is a recovery-setup failure, not a server crash. In a full three-member test, configure the same CA/certificate/key path on a joining member and force distributed recovery to select Clone. Actual result MySQL 8.4.11 accepts and stores the apostrophe-bearing GR recovery path. The unescaped SQL generated from that value fails parsing with error 1064. The full GR-to-Clone transition was not executed in the available single-node setup. Expected result All path values accepted by Group Replication should be transferred to Clone without changing SQL syntax. The joining member should either begin Clone or fail later for an actual file/TLS reason, not because generated SQL is invalid.