Historically Drush has integrated with MySQL by specifying the username and password on the command line. This can lead to credentials being leaked, through simple server diagnostics like listing the active processes. A straightforward fix is to use the command-line --defaults-extra-file=FILE option, writing and then specifying a temporary file that only the current user has permission to access. This was successfully implemented on March 30.
Howevever, this fix could cause your MySQL configuration to apparently "break". This is because the --defaults-extra-file route for authentication (a) overrides your global /etc/my.cnf but then (b) defers to your personal configuration in ~/.my.cnf. From the MySQL documentation linked above:
--defaults-extra-file=file_name
Read this option file after the global option file but (on Unix) before the user option file.
That means that the credentials that drush sql-cli eventually uses to connect could be different! On my local build, I found that Drush 7.x could not connect to a Drupal 8 database, and was trying to do so using a completely different user account; however, drush sql-connect will still output the username and password credentials in full, so according to that diagnostic all should still have been fine.
The simplest fix is to remove your personal ~/.my.cnf file; more complex solutions are available, once you know that it's the my.cnf that has sprung back to life!
