Unable to repro this issue on Ubuntu Trusty (14.04) for Google Chrome Dev Version - 53.0.2767.4

Screen-recording is attached.

@gwhite: Could you please re-test the same on a clean profile [chrome://settings -> Add Person] and let us know your observations.

Thank you.

Deleted: 621378.ogv 9.7 MB

	621378.ogv 9.7 MB View Download

I did start from a fresh profile.

My bad.  It would appear that a restart of gnome-keyring-daemon is required.

Here's how I got this to reproduce:

(1) Start with a fresh Chrome profile and kill gome-keyring-daemon.  You can also delete the keyring called 'Default keyring', just to start from scratch.

(2) Launch chrome.  gome-profile-daemon should prompt you to create Default keyring.  Do this thing.

(3) Login to chrome.

(4) Exit chrome.

(5) Kill gnome-keyring-daemon [nb: this basically simulates restarting your login session, from the keyring point of view.]

(6) Start chrome.

(7) Note that the chrome user profile now requires a sign in.
 
(8) If you look in Default keyring before/after killing the daemon, you will note that the chrome data is still there.

gnome-keyring-daemon version:

gwhite@ringle ~$ gnome-keyring-daemon --version
gnome-keyring-daemon: 3.20.0
testing: enabled

Also, note that gnome-keyring-daemon is *still* used, even if chrome is launched with --password-store=basic or --password-store=kwallet

Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

One other data point: disabling gnome-keyring-daemon will fix this problem.  Hardly ideal.  Where is chrome storing my private data?  I don't see it connected to kwallet....

Could someone from Dev team please look into this issue.

The reporter has mentioned to disabling gnome-keyring-daemon.

Thank you.

Issue still present on Chromium 53.0.2785.116.
Tested on Arch Linux, Gnome keyring version: 3.20.0.

 Issue 645287  has been merged into this issue.

If I manually unlock Gnome keyring before I start Chromium, everything is fine, but if Chromium triggers unlock prompt on start, he complains that user need to login again, I guess Chromium tried to retrive data from keyring before I entered password and therefore unlocked keyring, looks like some race condition, or some timeout for waiting user to unlock keyring is to small?

Any progress on this?

Issue 645474 has been merged into this issue.

+ewald@, nothing changed in signin code that should affect this. I suspect there might have been a change to how Chrome interacts with gnome-keyring per #10 and other comments here and in the dupe bugs.

Any idea who could know how to triage this?

+cfroussios, who's been working on OSCrypt. Any insight about this, especially considering comment #10? Thanks!

+Rachel for help triaging from desktop perspective

+thomas for Linux, and +vasilii for password manager in case he knows what changed here or how to fix this

sounds like a dupe of  bug 631171 
cfroussios@ can you confirm?

I want to add that it works if I change default keyring to have no/empty password.

Also in password protected scenario in which Chromium prompts for password but requires re-authenticating, if I re-authenticate, stop Chromium, than manually lock keyring again, than start Chromium again, it will prompt for password and successfully unlock keyring, and will keep successfully unlocking (there is caveat) until one restart keyring daemon. Caveat is that it seems Chromium can't retrieve cookies in this case as I noticed that some sites' settings are be lost.

When re-authentication is required I see this in log:

[6634:6634:0928/213554:ERROR:account_tracker.cc(357)] OnGetTokenFailure: Not authorized.
[6634:6634:0928/213554:ERROR:account_tracker.cc(357)] OnGetTokenFailure: Not authorized.

After reauthenticating:

[6857:6897:0928/213740:ERROR:gcm_store_impl.cc(922)] Failed to restore security token.
[6857:6879:0928/213743:ERROR:mcs_client.cc(706)] Failed to log in to GCM, resetting connection.
[6857:6857:0928/213750:ERROR:data_type_manager_impl.cc(34)] Passwords cryptographer error was encountered: 

Then after restart:

[7078:7118:0928/213825:ERROR:gcm_store_impl.cc(627)] LevelDB remove failed: NotFound: 
[7078:7100:0928/213825:ERROR:mcs_client.cc(524)] GCM Update failed!

This does sound like a duplicate of  issue 631171 . I'm going to merge it.