MySQL Bugs: #74771: Passwords not being saved in keychain

Bug #74771	Passwords not being saved in keychain
Submitted:	10 Nov 2014 19:55	Modified:	23 Jan 2015 0:30
Reporter:	Prw H1x4	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S3 (Non-critical)
Version:	6.0.8.11354	OS:	Linux (Ubuntu 14.04)
Assigned to:		CPU Architecture:	Any

Description:
When I open a saved connection in Workbench previously I've been prompted once for my keychain password, then stored passwords are used. That no longer happens - I get prompted for the MySQL passwords every time (local and remote). The "save password in keychain" checkbox is still on the password dialog box, but ticking it has no effect.

The workaround suggested in http://bugs.mysql.com/bug.php?id=51673 dos not work - going into connection manager and hitting the "store in keychain" button has no effect either.

Passwords appear to be saved until I restart Workbench, but I'm not sure whether that's a separate feature.

How to repeat:
- Save a connection to a password protected database
- connect, ticking the "save password in keychain" checkbox
- close Workbench
- re-open Workbench
- open the saved connection
- note that you're being asked for the database password

Suggested fix:
The previous behaviour was better - ticking "save password in keychain" saved the password in the keychain.

Thank you for the bug report. I couldn't repeat on Mint 17 with 6.2.3 version please try this version. Thanks.

I've now installed 6.2.3.12312 and the behaviour is different.

Now, if I go into "Database - Manage Connections" the first saved databases in the list is shown but is greyed out - I have to select the second entry (not greyed) then select the first again.

If I hit "Test Connection" I'm prompted for the SQL password and ticking the "save password in keychain" box has no effect. If I hit the "test connection" button again immediately it works with no password. But if I switch to the second saved connection and enter that password, then back to the first, hitting "test connection" once again prompts me for the SQL password.

Even hitting "Store in Keychain" button doesn't work - I press that, paste in the password (and tick "store password in keychain"), then immediately hit "test connection"... which prompts me for the password.

I don't see any MySQL entries in the keychain tool either. It seems that the "manage connections" dialog stores the most recently entered password, if I change to the second save connection then back without entering a different password the "test connection" button works without prompting me again.

Also, FWIW when I finished a few hours of modelling with quite a few forward and reverse engineering runs (complete with typing the password in every single time), Workbench crashed when I shut it down. I can't reproduce that easily (starting it up, reverse engineer then forward engineer works fine) because I've made quite a few database changes then applied them to both local and remote databases as well as sucking in changes from a remote database. But just so you know...

Thank you for the feedback. Got the below message on Debian Testing box please check if you case too.

miguel@cuzca:~$ mysql-workbench
** Message: Gnome keyring daemon seems to not be available. Stored passwords will be lost once quit
['un\\"o', 'do``s']

Yes, exactly. I never thought of running it from the command line. What I get has one extra line:

~$ mysql-workbench
/usr/bin/mysql-workbench-bin: /usr/local/lib/libcurl.so.4: no version information available (required by /usr/lib/mysql-workbench/libgdal.so.1)
** Message: Gnome keyring daemon seems to not be available. Stored passwords will be lost once quit
['un\\"o', 'do``s']

Although Chrome seems to find the keyring daemon just fine. I suspect an API change :(

Thank you for the feedback.

Sorry, but I can't see how this is "not a bug". Workbench is failing to connect to the keyring daemon when Chrome can. The documentation and GUI say that it can connect to the keyring, and it used to be able to.

If Workbench is no longer supposed to connect to the keyring can I change the bug report to "User interface mentions keyring in multiple places when keyring is no longer supported"?

No, really, it's a bug.

Sorry, somehow my attempt to change the status to "open" closed it. So if you accidentally changed it to "not a bug", sorry if my reply seems accusatory. Hence my "really, it's a bug" since I had to leave a comment when I changed the status.

Which window manager are you using, is it the default one that comes with Ubuntu or it's something different?
Also I'd like to ask you to paste the output of this command:
printenv | grep -i keyring

Yes, the default ubuntu window manager.

GPG_AGENT_INFO=/run/user/1000/keyring-tghYFD/gpg:0:1
SSH_AUTH_SOCK=/run/user/1000/keyring-tghYFD/ssh

Thank you for the feedback. 

Can you give me the output of this command also, please?

gnome-keyring version

~$ gnome-keyring version
gnome-keyring: 3.10.1

http://bugs.mysql.com/bug.php?id=74909 marked as duplicate of this one.

Thank you for the feedback.
Can you try something else?
PLease check the output of this command:
printenv | grep -i XDG_RUNTIME_DIR
and if it will be present, 
please try to call this before launching WB from command line
export GNOME_KEYRING_CONTROL=1
and please let us know if it worked for you.

Yes, that worked, thanks. I have keyring support again. 

I've pasted the errors from the terminal in case those are interesting, as they don't seem to be fatal.

Although I suspect you will be making code changes in the background, this workaround works for me now . So I'm happy :)

$ printenv | grep -i XDG_RUNTIME_DIR
XDG_RUNTIME_DIR=/run/user/1000

$  /usr/bin/mysql-workbench&
/usr/bin/mysql-workbench-bin: /usr/local/lib/libcurl.so.4: no version information available (required by /usr/lib/mysql-workbench/libgdal.so.1)
['un\\"o', 'do``s']
Ready.
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: attempting to add an interface (GtkTreeModel) to class (gtkmm__CustomObject_13GridViewModel) after class_init
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: attempting to add an interface (GtkTreeDragDest) to class (gtkmm__CustomObject_13GridViewModel) after class_init
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: attempting to add an interface (GtkTreeDragSource) to class (gtkmm__CustomObject_13GridViewModel) after class_init
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_14CustomRendererIN3Gtk16CellRendererSpinEN4Glib7ustringEiE::pixbuf after class was initialised
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_14CustomRendererIN3Gtk16CellRendererSpinEN4Glib7ustringEiE::text after class was initialised
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_14CustomRendererIN3Gtk16CellRendererSpinEN4Glib7ustringEiE::editable after class was initialised
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_14CustomRendererIN3Gtk16CellRendererTextEN4Glib7ustringES3_E::pixbuf after class was initialised
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_14CustomRendererIN3Gtk16CellRendererTextEN4Glib7ustringES3_E::text after class was initialised
(mysql-workbench-bin:10621): GLib-GObject-WARNING **: Attempt to add property gtkmm__CustomObject_14CustomRendererIN3Gtk16CellRendererTextEN4Glib7ustringES3_E::editable after class was initialised

Thank you for the bug report.

One other thing: this keeps popping up in the terminal I started workbench from. Hopefully easy to fix as well as locate:

(mysql-workbench-bin:6695): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1 char 586: '=' is not a valid character following a '<' character; it may not begin an element name

Thank you for the feedback. 
As this looks like different kind of issue, I'd like to ask you to report it as a separate bug. With step by step information how to reproduce this situation.

Posted by developer:
 
Fixed as of the upcoming MySQL Workbench 6.2.5 / 6.3.0 releases, and here's the changelog entry:

On Linux, the "Saved password in keychain" functionality for a MySQL
connection would not always save correctly. A possible workaround was to
execute "export GNOME_KEYRING_CONTROL=1" before starting MySQL Workbench.

Thank you for the bug report.

Still reproducible with 6.3.4.0 version on Ubuntu 14.04.

The workaround was:

sh@sh--work:~$ export GNOME_KEYRING_CONTROL=1

Still reproducible with version 6.2.3.12312, on Linux Mint Debian Edition.

GNOME_KEYRING_CONTROL=1 workaround is effective, however when run from a new terminal window, I receive the following:

me@lmde ~ $ mysql-workbench
** Message: Gnome keyring daemon seems to not be available. Stored passwords will be lost once quit
['un\\"o', 'do``s']
Ready.

*sigh*

My apologies, I didn't realise the package in the LMDE repo was such an old version.  Please disregard my comment.

Same problem on debian 8 lxde , when i save the pw in keychain it dont save...