It seems users are still disturbed at creating passwordless users in mysql for mysql-check. https://discourse.haproxy.org/t/haproxy-mysql-check-user-removal/6685
I certainly understand not wanting to implement the truly ugly implementation that is the protocol to support multiple password mechanisms ( mysql_native_password, mysql_caching_sha256_password etc). As a middle ground, would you be willing to take a haproxy patch that: * accepts an account locked error on the client as a valid state?; and/or * offer the CLIENT_CAN_HANDLE_EXPIRED_PASSWORDS client capability and accept the password expired error ( 1820) as a valid state? This would enable users to deploy a user account for MySQL and MariaDB that is truly unusable and make the assessment to use this functionality easier from a risk management point of view. On the mysql/mariadb server side both of these are Notes like below: 2021-07-01T04:41:03.144498Z 4554 [Note] Your password has expired. To log in you must change it using a client that supports expired passwords. 2021-07-01T04:57:30.706593Z 5056 [Note] Access denied for user 'haproxy'@'10.0.2.100'. Account is locked. This has the consequences that: * these aren't counted as connection errors therefore reaching the default 100 max_connect_errors isn't hit because of this. * dropping MySQL's log_error_verbosity=2 from 3(default) will hide these informational messages from the logs that would otherwise be quite noisy while not hiding anything else too significant. In the same area of code, dropping the MySQL-4.0 protocol support is probably called for given the MySQL-5.0 was end of support in January 9, 2012 https://endoflife.software/applications/databases/mysql . 4.1 protocol is still in use.
