--conf password silently truncated at ; (gcfg treats it as a comment), causing spurious Error 1045

Summary

When the MySQL password supplied via --conf contains a semicolon (;), gh-ost authenticates with only the portion before the ;, resulting in Error 1045: Access denied. The same credentials work when passed on the command line or used directly with the mysql CLI, which makes this look like an auth/driver/MySQL-version problem when it is actually a config-parsing issue.

2026-08-14 12:54:31 INFO starting gh-ost 1.1.10 (git commit: 835f5379afe7318d80d4f347016e3d81721327c7)
2026-08-14 12:54:31 INFO Migrating `ABC`.`Table1`
2026-08-14 12:54:31 INFO Tearing down inspector
2026-08-14 12:54:31 FATAL Error 1045 (28000): Access denied for user 'ghost'@'server.domain' (using password: YES)

Environment

• gh-ost version: 1.1.10 (git commit: 835f5379afe7318d80d4f347016e3d81721327c7)
• MySQL server: 8.4.8-8 Percona Server (GPL), Release 8, Revision 1c288264
• OS: Rocky Linux 9.7 (Blue Onyx)

Steps to reproduce

1. Create a config file with a password that contains a ;:
   ini复制

   [client]
   user=migrator
   password=foo;bar

2. Run gh-ost with --conf=/path/to/that.cnf.
3. Observe authentication failure.

Expected

The full password foo;bar is used and authentication succeeds.

Actual

Only foo is sent as the password, producing Error 1045: Access denied for user 'migrator'.

Root cause

gh-ost parses --conf with the gcfg library, which treats ; (and #) as inline comment characters. An unquoted value containing ; is truncated at the first ;. This is not a MySQL 8.4, driver, or authentication-plugin issue — the credentials are correct; they are being read incorrectly.

Quoting does not help

Wrapping the value in double quotes does not work — the password still fails to authenticate:

[client]
password="foo;bar"

Workarounds

Either of these avoids the broken --conf parsing:

• Pass the password on the command line instead of via --conf: --password='foo;bar' (shell-quoted, bypasses gcfg).
• Change/regenerate the account password so it contains no ; (or #).

Suggested fix

Handle passwords containing ; (and #) correctly when read from --conf, or at minimum document that these characters are unsupported in a --conf password so users don't hit a misleading Error 1045.