Even with USE="gnome-keyring" chromium does not store my saved passwords in gnome-keyring. If I run `chromium` and save a password, it appears only in Chromium's Personal Stuff -> Show Saved Passwords dialog, but not in Seahorse. If I run `chromium --password-store=gnome` or even `chromium --password-store=detect` and save a password, it saves the password in gnome-keyring so that it's visible from Seahorse. I might just not know enough about Chromium's password handling, but it seems to me that `chromium --password-store=detect` should be default.
*** This bug has been marked as a duplicate of bug 335758 ***
I'm going to reopen, as the the other bug looks like it's turned into "--password-store=detect" doesn't work with kwallet _sometimes_.
> I might just not know enough about Chromium's password handling, but it seems > to me that `chromium --password-store=detect` should be default. > Your suggestion has already been made by Mike at #335758 . That is the intended future behaviour anyway... See http://code.google.com/p/chromium/issues/detail?id=12351#c33 and From http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/814d112acb8944c2?pli=1 : <quote> I've recently committed r50475 which adds a new flag, --password-store, that lets you request GNOME Keyring or (KDE) KWallet instead of the built-in unencrypted password store. There are three possible values: --password-store=gnome --password-store=kwallet --password-store=detect (this will eventually be the default) </quote>
(In reply to comment #3) > Your suggestion has already been made by Mike at #335758 . That is the intended > future behaviour anyway... That's fine and well, but can't we (Gentoo) should go ahead and do this? If USE="gnome-keyring" then set --password-store=gnome/detect as default.
For what it is worth, I have been using KDE/kwallet for a few weeks with chromium-9999 builds, and have yet to notice the random failures mentioned in the other bug. Is that still a problem, or has it magically fixed itself? Unrelated: I think I like KDE better than GNOME, so I am sticking with this config for now.
(In reply to comment #5) > For what it is worth, I have been using KDE/kwallet for a few weeks with > chromium-9999 builds, and have yet to notice the random failures mentioned in > the other bug. > > Is that still a problem, or has it magically fixed itself? > Was still a problem when I decided to give a gnome-keyring a try --which is working fine though I don't like gnome. I did not try 9999. Upstream asked me to reproduce the issue with branded chrome. But I failed to do so on a system with USE="-cups".
(In reply to comment #4) > (In reply to comment #3) > > Your suggestion has already been made by Mike at #335758 . That is the intended > > future behaviour anyway... > > That's fine and well, but can't we (Gentoo) should go ahead and do this? If > USE="gnome-keyring" then set --password-store=gnome/detect as default. > (In reply to comment #4) > (In reply to comment #3) > > Your suggestion has already been made by Mike at #335758 . That is the intended > > future behaviour anyway... > > That's fine and well, but can't we (Gentoo) should go ahead and do this? If > USE="gnome-keyring" then set --password-store=gnome/detect as default. > In a post to other bug I had voted for it [detect]. Enabling it by checking against gnome-keyring would not be fair to kde users. Detect switch with only kwallet installed was not always working for me. I think they are waiting for enough number of 'works for me' before doing it.
(In reply to comment #7) > In a post to other bug I had voted for it [detect]. Enabling it by checking > against gnome-keyring would not be fair to kde users. Detect switch with only > kwallet installed was not always working for me. I think they are waiting for > enough number of 'works for me' before doing it. Look, I'm sorry kwallet+chromium doesn't work for you, but that's not a reason to prevent it from working for everyone else. If it's not fair to KDE users, it's because there's a bug between kwallet and chromium, and not that password storage does work with gnome-keyring. This is not an upstream bug. I'm suggesting adding --password-store=detect/gnome for USE="gnome-keyring" to chromium's desktop file. It won't affect you, so please...
Okay, here is my take: - Fatih is the currently only one who is able to reproduce the kwallet problem. - Upstream bug is stalled. Perhaps we could enable --password-store=detect in the dev channel releases to get additional feedback?
(In reply to comment #8) > (In reply to comment #7) > > In a post to other bug I had voted for it [detect]. Enabling it by checking > > against gnome-keyring would not be fair to kde users. Detect switch with only > > kwallet installed was not always working for me. I think they are waiting for > > enough number of 'works for me' before doing it. > > Look, I'm sorry kwallet+chromium doesn't work for you, but that's not a reason > to prevent it from working for everyone else. If it's not fair to KDE users, > it's because there's a bug between kwallet and chromium, and not that password > storage does work with gnome-keyring. > > This is not an upstream bug. I'm suggesting adding > --password-store=detect/gnome for USE="gnome-keyring" to chromium's desktop > file. It won't affect you, so please... > I am not against enabling the switch. I am for it. What I meant was enabling it by only checking against gnome-keyring use flag would not benefit users without gnome-keyring use flag. So perhaps it should be --password-store=detect unconditionally and --password-store=gnome if gnome-keyring use flag is present.
(In reply to comment #9) > Okay, here is my take: > - Fatih is the currently only one who is able to reproduce the kwallet problem. > - Upstream bug is stalled. > Unfortunately and oddly, yes. > Perhaps we could enable --password-store=detect in the dev channel releases to > get additional feedback? > Why not in the beta channel as well? Most people use beta I believe.
I'd rather avoid setting different defaults than the upstream. Feel free to file an upstream bug (search for duplicates first), and post the link here.
Is it still a problem with chromium-10.x? According to http://code.google.com/p/chromium/wiki/LinuxPasswordStorage the 10 series should have new defaults.
(In reply to comment #13) > Is it still a problem with chromium-10.x? According to > http://code.google.com/p/chromium/wiki/LinuxPasswordStorage the 10 series > should have new defaults. > It doesn't work automatically for me on 10.0.612.1-r1. I am running KDE 4.4 with USE="-gnome-keyring". When I run chromium --password-store=detect, it finds KWallet and uses that; without --password-store, it still uses the built-in password store.
Just my experience with gnome: I'm using chromium-9999 (10.0.628.0 (70411)) and gnome-keyring USE Until now chromium (launched without --password-store switch) seems to use builtin password store with my profile (used for a long time). With an empty profile, it automatically uses gnome password store. When I explicitely launched with chromium --password-store=gnome with my old profile, passwords from built-in store has appeared in seahorse (?? don't know why, automatic migration?). And now if I relaunch chromium without --password-store switch, it automatically uses gnome keyring).
> I'm using chromium-9999 (10.0.628.0 (70411)) and gnome-keyring USE > > Until now chromium (launched without --password-store switch) seems to use > builtin password store with my profile (used for a long time). > > With an empty profile, it automatically uses gnome password store. I use www-client/chromium-9.0.597.67 with +gnome-keyring, and I've deleted my whole profile (~/.config/chromium), but the passwords are still not stored in the GNOME keyring. I don't issue any command line option. Is the default of saving in a auto-detected keyring only in later versions of chromium?
> I use www-client/chromium-9.0.597.67 with +gnome-keyring, and I've deleted my > whole profile (~/.config/chromium), but the passwords are still not stored in > the GNOME keyring. I don't issue any command line option. Is the default of > saving in a auto-detected keyring only in later versions of chromium? > Yes, Gnome keyring is used by auto-detection and by default only from chromium 10. "Support for using GNOME Keyring and KWallet was added in version 6, but using these (when available) was not made the default mode until version 10." http://code.google.com/p/chromium/wiki/LinuxPasswordStorage
(In reply to comment #17) > Yes, Gnome keyring is used by auto-detection and by default only from chromium > 10. Thank you. Then I'll try version 10 as soon as I find some time.
Ok, now I have chromium-10.0.642.2-r1 with USE=gnome-keyring installed and started over with a fresh profile (deleted ~/.config/chromium/ and ~/.cache/chromium/). How can I validate that it really uses the gnome keyring? I don't have gnome installed (I use XFCE), so I don't have a GUI for the keyring (AFAIK). And in the chromium preferences, the passwords are listed as usual... (The tip "check if you are asked for your keyring password when saving a new password in chromium" doesn't work because of a hen-and-egg problem. I need to unlock the keyring to make NetworkManager login to the network before I can start working in chromium...)
You could try to install seahorse to check stored passwords in gnome keyring.
(In reply to comment #20) > You could try to install seahorse to check stored passwords in gnome keyring. Ah, that's the name of the GUI. I searched for "keyring" using eix -S, but the description of seahorse doesn't contain that. Anyway, now I could check that the passwords are indeed in the keyring (application: chrome in the details tab). Great!
This bug could perhaps be closed now since behavior will be correct in chromium 10 and later.
(In reply to comment #22) > This bug could perhaps be closed now since behavior will be correct in chromium > 10 and later. That's very likely. Matt, could you confirm it's fixed for you with >=chromium-10?
Yes, indeed. It is fixed in Chromium-10. Marking fixed.
*** Bug 352821 has been marked as a duplicate of this bug. ***
