My apologies, Security may have been the wrong category, I didn't realize this would be flagged so high-pri or hidden.

Removing security label.

This is unlikely to be looked at - we save cookies to a file on disk.  We load them all into memory when Chrome starts.  That hasn't changed significantly in quite a while.

That's unfortunate as I can very easily, trivially repro this.

Logged into Gmail. Rebooted. Launched 'seahorse' and unlocked the keychain before starting Chrome. Gmail is still logged in.

Rebooted again. Launched Chrome witout unlocking the keychain first... I am prompted to unlock the keychain. Gmail is NOT logged in.

[+shess,+gbillock] I suppose this may be due to a change in sqlite, or our wrapper around it.

I also see a behaviour change here recently.

A) I'm now being asked to unlock my keyring when I start my browser where I was not before (I don't want to be asked, I don't want to unlock my keyring).

B) Regardless of whether I unlock the keyring, I am logged out of all sites, as though cookies are not being set.

Here are several other reports around the internet of people on Ubuntu recently experiencing cookie loss:

https://productforums.google.com/forum/#!topic/chrome/3wSqHNDdH3M
http://stackoverflow.com/questions/39425499/google-chrome-losing-cookies-after-ubuntu-reboot
https://superuser.com/questions/1122965/google-chrome-on-ubuntu-cookies-issue/1123026#1123026

I can confirm I have the same bug, exactly as described by the comment #6.

Started happening couple of days ago.

Chrome: Version 53.0.2785.92 (64-bit)
OS: Ubuntu 16.04 LTS

I have the same bug. I believe I started seeing it like 2 weeks ago, after updating Chrome.

Chrome: 53.0.2785.116 (64-bit)
OS: Ubuntu 14.04 LTS

Any chance this relates to  issue 640603  ?

Same issue here on CentOS 7 with both Chrome 53.0.2785.116 (64-bit) and Chrome Beta 54.0.2840.27 (64-bit).
Just as said in Comment 4 launching Seahorse and unlocking Keyring before starting Chrome thinks are ok.

Chromium 53.0.2785.116 (64-bit) on Arch Linux here. Even though my keyring is set to unlock automatically (and it does), logins are gone every time I reboot or log out then log in again.

The funny thing is... only SOME logins are gone. For example, I lose the login for gmail, github and a couple other sites but I'm still be logged on to youtube (except the language and location get reset).

Any other programs that depend on the default keyring work fine, only Chromium has this issue.

I have to add that if I forget to manually unlock Keyring via Seahorse before starting Chrome for the first time in a session, beside Chrome not reading stored cookies it seem to corrupt cookie database too, because if I successively close Chrome, unlock keyring and restart Chrome, it still is no more able to access store cookies and I have to re-login everything.

It's very likely related to the fact that the cookies are stored encrypted. The encryption key since recently resides in the Keyring. Therefore, when the Keyring is locked on startup the cookies are unavailable.

Before anything else, we should clarify that running Chrome without access to Keyring, when it had access in a previous run, will result in data loss (e.g. cookies). As Vasilii responded, that's because access to Keyring affects the ability to encrypt/decrypt profile data.

I am interested in the cases, where sessions are lost, despite granting access to keyring. I am unable to reproduce the problem on 53.0.2785.116, using the steps described. Could you provide some more answers?

First, can you verify that Chrome is using Keyring for encryption? You can open Seahorse and look if there exists an entry named "Chrome Safe Storage".

If the above is true, can you check if the problem also occurs when you do the following:
1. Unlock keyring.
2. Launch Chrome.
3. Create sessions (open Gmail etc)
4. Close all Chrome windows.
5. Close Chrome from the background (right click on Chrome icon on the tray).
6. Lock keyring (from Seahorse, right click on the keyring)
7. Launch Chrome
Expected: You will be prompted to unlock. Chrome will not load pages until you react.
8. Unlock keyring.
Expected: Pages load and sessions are resumed.

I am also having this problem.  I verified that Chrome is using keyring for encryption, and following the 8-step test in #c14 leads to expected behavior.

After much testing, the only way I can trigger the bug is to reboot the system and launch Chrome while the keyring is locked (and has never been unlocked since boot).  If the keyring has been unlocked at least once since boot, then the problem goes away regardless of whether the keyring is locked when I launch Chrome.

I suspect there is a race condition that makes Chrome attempt to retrieve cookies without confirming that the keyring has been fully unlocked.  Initial unlock is always a bit slower (due to the need for disk access), so Chrome is much more likely to fail when retrieving cookies from keyring.  Once the keyring has been accessed at least once, it resides in kernel buffer cache, so unlock becomes much faster and makes the cookie retrieval less likely to fail.

Thanks for testing this! I have managed to reproduce the problem by logging in and out.

I also suspected a race condition, and I believe I have found a possible cause. However, I have yet to understand why the steps in #14 succeed consistently, when they should be subject to the same race condition.

Please change status to confirmed:

- http://askubuntu.com/questions/822804/after-rebooting-i-need-to-log-in-each-time/827964#827964 
- https://productforums.google.com/forum/#!topic/chrome/3wSqHNDdH3M 

I think I have the same here.

I logout from Plasma 5 and log back in, start Chromium and I need to login again in my Google profile as well as in all other websites. I have never seen this before and now it happens every time. Interestingly - while my openSUSE user session is active (i.e. I don't logout) there is no problem to close Chromium completely and then start it again - all site sessions are preserved.

I checked my settings (although I haven't changed them) - for Cookies I have "Allow local data to be set (recommended)" which is the default. I have "Block third-party cookies and site data" on but so far it has never been a problem. And it obviously isn't while my Plasma 5 session is active.

I browsed the web for different solutions. I recreated a new Chromium profile from scratch etc but that changed nothing. I also tried stopping the browser, deleting ~/.config/chromium/Default/Cookies and Cookies-journal and starting the browser again. Nothing seems to help.

I am using seahorse for passwords storage and I unlock my keyring manually after each login to Plasma 5, before starting any browser. It has been this way for a long time and never caused any issues. For Firefox I also use seahorse and there is no such issue there.

P.S.

I think it might be related to cookies somehow because Facebook also asks me to confirm my browser again after each new login + some other sites also seem to forget settings which I have set in them (e.g. YouTube turns on Autoplay which I previously set to off).

I am probably having the same issue, made an issue of it: https://bugs.chromium.org/p/chromium/issues/detail?id=648868

Chrome version: 53.0.2785.116  Channel: stable
OS Version: Elementary OS Loki (Ubuntu 16.04)

I also have autologin enabled, and need to type my password when I boot up Chrome

Autologin is definitely part of the missing link. The problem went away for me when I upgraded my machine from 14.04 to 16.04, also removing autologin. My wife uses 16.04 and has autologin enabled, and the problem has just started manifesting for her.

Update:

I think I found a workaround.
I didn't mention that before but I have several keyrings: 1) Login 2) Default keyring (which chromium uses) 3) etc...

So far it was enough to unlock the Login one which automatically unlocks the others. But it seems not sufficient any more. Now I tried a new login to Plasma 5, then unlocked manually Login keyring (as usual) but now I also unlocked manually the Default keyring too, i.e. before starting chromium. And now the login sessions in the browser are persistent.

I wonder if this is an issue with chromium or with seahorse. The actual problem seems that chromium is unable to unlock its keyring.

There was definitely an issue from the side of Chrome, which I am fixing. If there are more layers to this problem, we will find out in time.

Many thanks to the people who have been helping diagnose!

 Issue 648868  has been merged into this issue.

https://bugs.chromium.org/p/chromium/issues/detail?id=552790
Another possible dupe?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc6f304827896fb27397fc2a27f9f5717eff319c

commit fc6f304827896fb27397fc2a27f9f5717eff319c
Author: cfroussios <cfroussios@chromium.org>
Date: Tue Sep 27 04:11:15 2016

Thread safe initialization of OSCrypt cache

Clients of OSCrypt run in multiple threads. This creates a race
condition for the lazy initialization of OSCrypt, which currently
isn't thread safe.

Additionally, when a synchronous call to libsecret blocks waiting for
user permission, parallel calls to it do not block on the same prompt.
Rather, they fail. This means that, while the first caller will
correctly identify that encryption should be used, subsequent callers
will behave as if full encryption is not available, until the first
caller gets permission and properly initialises OSCrypt.

Fixing thread safety should fix reported cases of data loss.

BUG= 631171 

Review-Url: https://codereview.chromium.org/2359803002
Cr-Commit-Position: refs/heads/master@{#421097}

[modify] https://crrev.com/fc6f304827896fb27397fc2a27f9f5717eff319c/components/os_crypt/os_crypt.h
[modify] https://crrev.com/fc6f304827896fb27397fc2a27f9f5717eff319c/components/os_crypt/os_crypt_linux.cc
[modify] https://crrev.com/fc6f304827896fb27397fc2a27f9f5717eff319c/components/os_crypt/os_crypt_unittest.cc

Some additional instructions for those who attempt to reproduce this. The easiest way I know to reprocude this is:
1. Open Chrome, create cookies (e.g. login into Gmail)
2. Close Chrome
3. Set keyring to not unlock (see points at the end of this comment)
4. Log out and in.
5. Start Chrome.
6. Unlock access to keyring.
Expected: sessions resume.

Additional info for locking keyring:

1. Keyring must not unlock automatically when logging in. A way to ensure that is to lock the keyring and change the password for keyring to something other than the Linux user's password. (both doable through Seahorse by right-clicking the keyring). Both of these actions are necessary. Then you can log out and in again.

2. Your system may be set up in such a way that the password to keyring is automatically reset to be the Linux user's password every time you unlock it. If that is the case, every time you try to reproduce this, you need to change the password again (see point 1).

re. comment 29:

Are you suggesting that the set up described in comment 23 is wrong and that actually it is expected to manually unlock the keyring mentioned there as 2)? Please clarify.

Another question: is it possible to tell chromium explicitly which particular keyring to use? If not - how can I turn this question into a feature request?

re #30

It is required that you grant access to keyring. It is not required that you do it manually. Comment 29 is to help those who wish to verify the fix (which is not in version 53).

Any setup should theoretically work or we have another bug. That said, the setup that you described sounds unusual to me and I doubt that anyone is going to test it explicitly.

With regards to your feature request, it is currently not supported. Feel free open a feature request bug for it.

re #31

It is not unusual to have separate layers of security. There is one Login keyring which rules the other keyrings. Obviously it is preferable to have chromium store its data in a separate keyring rather than having all applications storing (and hence being able to read) all data in the same keyring, no? Also from usability viewpoint it is more convenient to unlock only the main keyring which contains the unlocks for the other separate keyrings.

Re. feature request: could you please give me a link or a direction how to find a page for submitting it?

Thanks!

There's a new issue button on the top left. Select type "feature request". The component for this is probably Passwords.

Done. Thank you.

https://bugs.chromium.org/p/chromium/issues/detail?id=650600

 Issue 621378  has been merged into this issue.

Resetting my profile would not help. Remove the keyring databases wouldn't help. The problem is very annoying. I'm on Linux Mint 18 at home where the problem occurs and also at my work where the problem is not happening at all.

Also caused by Auto login on Linux.  If you disable Auto login and enter
password at login prompt then issue doesn't occur.

Can we merge r421097 and r421605 into M54?

This affects Linux (Gnome) users with a certain setup on gnome-keyring. Those users are experiencing loss of saved cookies when doing a cold start of Chrome and gnome-keyring.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

Could you please confirm whether this change is baked/verified in Canary and safe to merge?If yes, please merge to M54 ASAP.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293

commit 0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293
Author: Vaclav Brozek <vabr@chromium.org>
Date: Tue Oct 04 14:34:24 2016

Thread safe initialization of OSCrypt cache

Clients of OSCrypt run in multiple threads. This creates a race
condition for the lazy initialization of OSCrypt, which currently
isn't thread safe.

Additionally, when a synchronous call to libsecret blocks waiting for
user permission, parallel calls to it do not block on the same prompt.
Rather, they fail. This means that, while the first caller will
correctly identify that encryption should be used, subsequent callers
will behave as if full encryption is not available, until the first
caller gets permission and properly initialises OSCrypt.

Fixing thread safety should fix reported cases of data loss.

BUG= 631171 

Review-Url: https://codereview.chromium.org/2359803002
Cr-Commit-Position: refs/heads/master@{#421097}
(cherry picked from commit fc6f304827896fb27397fc2a27f9f5717eff319c)

Review URL: https://codereview.chromium.org/2385413003 .

Cr-Commit-Position: refs/branch-heads/2840@{#635}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293/components/os_crypt/os_crypt.h
[modify] https://crrev.com/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293/components/os_crypt/os_crypt_linux.cc
[modify] https://crrev.com/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293/components/os_crypt/os_crypt_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9cad87469af6db5d25c08c956028f7f76dcafb53

commit 9cad87469af6db5d25c08c956028f7f76dcafb53
Author: Vaclav Brozek <vabr@chromium.org>
Date: Tue Oct 04 14:39:37 2016

Fix race condition on OSCrypt linux

This fixes the test that is broken on tsan.

BUG= 650902 , 631171 

Review-Url: https://codereview.chromium.org/2377973002
Cr-Commit-Position: refs/heads/master@{#421605}
(cherry picked from commit 840961a10fc0c0e24299ced23a60908ffa09e9d1)

Review URL: https://codereview.chromium.org/2390283002 .

Cr-Commit-Position: refs/branch-heads/2840@{#636}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/9cad87469af6db5d25c08c956028f7f76dcafb53/components/os_crypt/os_crypt_linux.cc

Hi,

Yesterday I updated my openSUSE and chromium package got an update too. Now I am using Version 53.0.2785.143 (64-bit). What I notice is:

1. The Default keyring which I mentioned in an earlier comment now gets successfully unlocked when starting chromium

2. Unfortunately regardless of that the cookies seem to be lost again as I need to relogin again on all sites.

Tested this issue on Ubuntu 14.04 using chrome latest Beta M54-54.0.2840.50 by following steps mentioned in the comment #29. Observed the below behavior

1. Opened up Chrome
2. Navigated to gmail.com
3. Logged in to gmail
4. Restarted Chrome
5. Keyring pop up displayed immediately 
6. Entered password
7. Observed chrome resumed gmail without asking to login as expected

Confirming the fix is working as expected, Hence adding TE-Verified label.

I just upgraded to Version 54.0.2840.59, and this bug is still not fixed.

If I unlock the keyring in seahorse before starting Chrome for the first time in the session, Chrome has access to my previous cookies.

If I start Chrome for the first time in the session while the keyring is still locked, Chrome loses my previous cookies.

It is exactly the same problem as I experienced in M53.  I am not sure why the bug could have been verified - perhaps because the verification procedure in #46 does not involve logging out and logging back in between restarts, thus so it did not trigger the bug?

Assigning back to the owner. cfroussios@ could you please take a look.

chklin@, did you get a UI prompt to unlock the Keychain?

Chrome isn't supposed to have your cookies if the Keyring is locked. The cookies may be encrypted and decryption is impossible without knowing the key stored in the Keyring.

I am able to reproduce the bug on beta 54, but not on unstable 55. I also verified that the fix exists in both versions. It is unclear why the problem appears to be fixed in 55 but not 54. This requires further investigation.

Since the problem is in 53 already, I do not see a major benefit to blocking the release on this.

If I launch Chrome while the keychain is locked, Chrome shows a UI prompt to unlock the keychain (same UI prompt as unlocking keychain in seahorse).  Typing the right password into the prompt unlocks the keychain, as expected, but Chrome still loses the cookies.

Since I'm still quite new to the Linux world, I don't know much about this keychain thing (and/or seahorse whatever that could be).

However, what I do know is that something (I guess this is the keychain) is unlocked automatically when I sign in to my user account.

Also, what I can confirm is that the issue regarding the loss of cookies after I restart my PC still persists in the latest stable release of Google Chrome (Version 54.0.2840.59 (64-bit)).

Sorry if I'm not really helpful here.

for me, the error still occurs with v54

- "Login" keyring is unlocked by gnome password login (gdm-password)
- "default" keyring is unlocked on first access by "Login" keyring

do a cold boot and login into gnome. start google-chrome: all cookies are gone, no one is logged in into "chrome-signin"

do a cold boot and login into gnome. before starting google-chrome, run something that access the "default" keyring.

% gkeyring --name 'Chrome Safe Storage'
12345   Chrome Safe Storage     [24 byte base64 encoded]

now start google-chrome. all cookies are there, my google account is in "chrome-signin"

% uname -r
4.7.5-200.fc24.x86_64

% lsb_release -s -d
"Fedora release 24 (Twenty Four)"

% localectl
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: de-nodeadkeys
      X11 Layout: de
     X11 Variant: nodeadkeys

% google-chrome --version
Google Chrome 54.0.2840.59

% rpm -qa \*keyring\* \*seahorse\* | sort
gnome-keyring-3.20.0-1.fc24.x86_64
gnome-keyring-pam-3.20.0-1.fc24.x86_64
gnome-python2-gnomekeyring-2.32.0-23.fc24.x86_64
libgnome-keyring-3.12.0-6.fc24.x86_64
seahorse-3.20.0-1.fc24.x86_64
seahorse-nautilus-3.11.92-6.fc24.x86_64

Same here as in #53

Unless the default keyring is unlocked manually or through another application that accesses it, Chromium does not unlock it.

Experiencing the same issue on Chromium 53, Ubuntu 16.04 with Gnome 3.20.

As per #50, not blocking M-54 Stable. It would be great to have a fix before M55 hits stable. 
Tagging accordingly, so bug will be in our triaging bucket.

 Issue 655165  has been merged into this issue.

re #54: Can you verify that Chrome does not unlock the keyring at all (emphasis on unlock)? That would be a different issue than the one investigated so far.

You can check by running seahorse. Note the name of the keyring that you were promted to unlock (should be the default keyring) and check the lock icon next to the keyring's name.

re #58: exactly! the keyring is not unlocked at all. the same as in v53.

i get NO prompt to unlock ANY keyring at all. because the "login" keyring is unlocked automatically via gnome login. and the "default" keyring (where all keys are stored) is unlocked automatically on first access via the "login" keyring.

if i start seahorse the "login" keyring is shown as unlocked and the "default" keyring as locked. i can click on then "default" keyring and it gets automatically unlocked.

imo this is the default behavior for any gnome installation.

similar to #59

However I am using Plasma, not Gnome and that's why I unlock my "Login" keyring in seahorse manually. After that I also manually unlock the "Default" keyring before running Chromium - otherwise the browser does not unlock it and there is no access to the cookies. Before that bug: after unlocking the "Login" keyring simply running Chromium unlocked the "default" keyring automatically.

Can confirm still happens on Ubuntu 16.04.1  with Chrome 54.0.2840.71

Logged in to many sites.  Reboot.  When opening chrome it opens all the previously loaded pages, and asks or the keyring password.  I enter it in, and it's not logged in.  Perhaps it should be asking for it before it tries to load anything or even attempt to read cookies?

Confirming this issue still exists on Antergos with XFCE. It only happens when I re-log in, though.

Still having it happen on Arch Linux, which recently updated the Chromium package to 54.0.2840.71. Both when unlocking the keyring manually and when doing it automatically on login through PAM. I have no DE or login manager or anything and use Openbox, but I still have gnome-keyring.

It's even more annoying now since I use 2fa for google itself and it makes logging in a chore every time I boot and open the browser.

cfroussios@ - Gentle Ping! Can we get any update on this bug ?

I have located and I am fixing a bug, where keyring items might not be unlocked. I think that bug can explain the loss of cookies. Once this is fixed on 56, I will test for and merge into 55 and 54 (the patch does not apply to 54 as is).

I still don't have a confident explanation why 55 appears to not be affected by the bug.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51e9b147713a497adcb228ae729a799872a35237

commit 51e9b147713a497adcb228ae729a799872a35237
Author: cfroussios <cfroussios@chromium.org>
Date: Mon Oct 24 14:28:31 2016

Unlock all libsecret items in Password Manager and OSCrypt

The various libsecret methods have different contracts w.r.t. unlocking
keyring items. Of the currently used methods, only secret_service_store
will trigger unlocking as necessary. As a result, operations fail in
various ways until someone performs the first store operation.

With the CL, the libsecret native backend of Password Manager is set to explicitly
request unlocking of items on every call. OSCrypt avoids using
secret_service_lookup, which apparently ignores locked items.

BUG= 657828 , 631171 

Review-Url: https://codereview.chromium.org/2441653002
Cr-Commit-Position: refs/heads/master@{#427067}

[modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/chrome/browser/password_manager/native_backend_libsecret.cc
[modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/chrome/browser/password_manager/native_backend_libsecret_unittest.cc
[modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/key_storage_libsecret.cc
[modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/key_storage_libsecret_unittest.cc
[modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/libsecret_util_linux.cc
[modify] https://crrev.com/51e9b147713a497adcb228ae729a799872a35237/components/os_crypt/libsecret_util_linux.h

Please request a merge to M55 if CL listed at comment #69 needs to be merged to M55. Thank you.

Apologies if it looks like I'm not keeping up with this issue.

I believe that the issue I tried to fix with r427067 (comment #69) is a bug in gnome's libsecret. I will communicate with them to confirm the bug and get feedback on how best to work around it. This may take a few days.

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293

commit 0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293
Author: Vaclav Brozek <vabr@chromium.org>
Date: Tue Oct 04 14:34:24 2016

Thread safe initialization of OSCrypt cache

Clients of OSCrypt run in multiple threads. This creates a race
condition for the lazy initialization of OSCrypt, which currently
isn't thread safe.

Additionally, when a synchronous call to libsecret blocks waiting for
user permission, parallel calls to it do not block on the same prompt.
Rather, they fail. This means that, while the first caller will
correctly identify that encryption should be used, subsequent callers
will behave as if full encryption is not available, until the first
caller gets permission and properly initialises OSCrypt.

Fixing thread safety should fix reported cases of data loss.

BUG= 631171 

Review-Url: https://codereview.chromium.org/2359803002
Cr-Commit-Position: refs/heads/master@{#421097}
(cherry picked from commit fc6f304827896fb27397fc2a27f9f5717eff319c)

Review URL: https://codereview.chromium.org/2385413003 .

Cr-Commit-Position: refs/branch-heads/2840@{#635}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293/components/os_crypt/os_crypt.h
[modify] https://crrev.com/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293/components/os_crypt/os_crypt_linux.cc
[modify] https://crrev.com/0f1b1d3b90aa54c9d6d72e8b13bbdcc4f3497293/components/os_crypt/os_crypt_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9cad87469af6db5d25c08c956028f7f76dcafb53

commit 9cad87469af6db5d25c08c956028f7f76dcafb53
Author: Vaclav Brozek <vabr@chromium.org>
Date: Tue Oct 04 14:39:37 2016

Fix race condition on OSCrypt linux

This fixes the test that is broken on tsan.

BUG= 650902 , 631171 

Review-Url: https://codereview.chromium.org/2377973002
Cr-Commit-Position: refs/heads/master@{#421605}
(cherry picked from commit 840961a10fc0c0e24299ced23a60908ffa09e9d1)

Review URL: https://codereview.chromium.org/2390283002 .

Cr-Commit-Position: refs/branch-heads/2840@{#636}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/9cad87469af6db5d25c08c956028f7f76dcafb53/components/os_crypt/os_crypt_linux.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f3a8dfe38fab661729155dac82c8ab7d8422c2e1

commit f3a8dfe38fab661729155dac82c8ab7d8422c2e1
Author: cfroussios <cfroussios@chromium.org>
Date: Fri Oct 28 15:30:32 2016

Add a dummy entry with libsecret when initializing OSCrypt.

Under certain conditions, gnome libsecret methods that perform a lookup
in keyring may ignore a locked keyring and return empty results, instead
of unlocking said keyring. Store operations are unaffected by this quirk
(or bug, presumably).

With this change, we store a dummy entry during the initialisation of
OSCrypt. This ensures that the default keyring gets unlocked and is
available for future reads.

This solution is also applied to Password Manager, before performing
calls to secret_service_search_sync.

This solution should be temporary, until the underlying issue gets fixed
or there is an official workaround.

BUG=660005, 631171 

Review-Url: https://codereview.chromium.org/2461453002
Cr-Commit-Position: refs/heads/master@{#428378}

[modify] https://crrev.com/f3a8dfe38fab661729155dac82c8ab7d8422c2e1/chrome/browser/password_manager/native_backend_libsecret.cc
[modify] https://crrev.com/f3a8dfe38fab661729155dac82c8ab7d8422c2e1/chrome/browser/password_manager/native_backend_libsecret.h
[modify] https://crrev.com/f3a8dfe38fab661729155dac82c8ab7d8422c2e1/chrome/browser/password_manager/native_backend_libsecret_unittest.cc
[modify] https://crrev.com/f3a8dfe38fab661729155dac82c8ab7d8422c2e1/components/os_crypt/key_storage_libsecret.cc
[modify] https://crrev.com/f3a8dfe38fab661729155dac82c8ab7d8422c2e1/components/os_crypt/key_storage_libsecret_unittest.cc
[modify] https://crrev.com/f3a8dfe38fab661729155dac82c8ab7d8422c2e1/components/os_crypt/libsecret_util_linux.cc
[modify] https://crrev.com/f3a8dfe38fab661729155dac82c8ab7d8422c2e1/components/os_crypt/libsecret_util_linux.h

I have had to deal with this bug since it was introduced (in 52? 53?). Are there any workarounds? I'm getting tired of having to login everywhere with 2FA enabled.

For a workaround, you can set the login keyring to be your default keyring.
Something to keep in mind is that Chrome will not copy data from one keyring to another when you do this. Passwords you've saved will become unavailable, unless you're syncing them online.

If you choose to do this, it's safer to do it while Chrome is closed.

Can we merge r427067 and r428378 into M55?

Your change meets the bar and is auto-approved for M55 (branch: 2883)

**** Bulk edit -  please ignore if not applicable ****

Please merge your change to M55 branch 2883 today before 5:00 PM PT or latest by tomorrow, Tuesday (11/01/16) 4:00 PM PT so we can take it for this week Beta release. 

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Unfortunately I'm having trouble using drover, and won't be able to merge this by that time. If another committer has two minutes to spare and is willing to merge this for me, please do. The patches should be applicable as they are. Apologies.

Darn.  Is it too late to merge?  govind@ I can do the merge in #79 asap if it's not too late

The CLs are ready to land:
https://codereview.chromium.org/2463263002/
https://codereview.chromium.org/2465083002/

govind@ PLMK if we can merge these

M55 Merges are auto approved at #80. Please merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3251aa60e867fa743741efbbe1fda61686ea30ca

commit 3251aa60e867fa743741efbbe1fda61686ea30ca
Author: thomasanderson <thomasanderson@google.com>
Date: Tue Nov 01 00:07:03 2016

Unlock all libsecret items in Password Manager and OSCrypt

The various libsecret methods have different contracts w.r.t. unlocking
keyring items. Of the currently used methods, only secret_service_store
will trigger unlocking as necessary. As a result, operations fail in
various ways until someone performs the first store operation.

With the CL, the libsecret native backend of Password Manager is set to explicitly
request unlocking of items on every call. OSCrypt avoids using
secret_service_lookup, which apparently ignores locked items.

BUG= 657828 , 631171 

Review-Url: https://codereview.chromium.org/2441653002
Cr-Commit-Position: refs/heads/master@{#427067}

NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2463263002
Cr-Commit-Position: refs/branch-heads/2883@{#401}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/chrome/browser/password_manager/native_backend_libsecret.cc
[modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/chrome/browser/password_manager/native_backend_libsecret_unittest.cc
[modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/key_storage_libsecret.cc
[modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/key_storage_libsecret_unittest.cc
[modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/libsecret_util_linux.cc
[modify] https://crrev.com/3251aa60e867fa743741efbbe1fda61686ea30ca/components/os_crypt/libsecret_util_linux.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc803359715785beade70e1af0a9b63930a6144d

commit dc803359715785beade70e1af0a9b63930a6144d
Author: thomasanderson <thomasanderson@google.com>
Date: Tue Nov 01 00:12:33 2016

Add a dummy entry with libsecret when initializing OSCrypt.

Under certain conditions, gnome libsecret methods that perform a lookup
in keyring may ignore a locked keyring and return empty results, instead
of unlocking said keyring. Store operations are unaffected by this quirk
(or bug, presumably).

With this change, we store a dummy entry during the initialisation of
OSCrypt. This ensures that the default keyring gets unlocked and is
available for future reads.

This solution is also applied to Password Manager, before performing
calls to secret_service_search_sync.

This solution should be temporary, until the underlying issue gets fixed
or there is an official workaround.

BUG=660005, 631171 

Review-Url: https://codereview.chromium.org/2461453002
Cr-Commit-Position: refs/heads/master@{#428378}

NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2465083002
Cr-Commit-Position: refs/branch-heads/2883@{#402}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/dc803359715785beade70e1af0a9b63930a6144d/chrome/browser/password_manager/native_backend_libsecret.cc
[modify] https://crrev.com/dc803359715785beade70e1af0a9b63930a6144d/chrome/browser/password_manager/native_backend_libsecret.h
[modify] https://crrev.com/dc803359715785beade70e1af0a9b63930a6144d/chrome/browser/password_manager/native_backend_libsecret_unittest.cc
[modify] https://crrev.com/dc803359715785beade70e1af0a9b63930a6144d/components/os_crypt/key_storage_libsecret.cc
[modify] https://crrev.com/dc803359715785beade70e1af0a9b63930a6144d/components/os_crypt/key_storage_libsecret_unittest.cc
[modify] https://crrev.com/dc803359715785beade70e1af0a9b63930a6144d/components/os_crypt/libsecret_util_linux.cc
[modify] https://crrev.com/dc803359715785beade70e1af0a9b63930a6144d/components/os_crypt/libsecret_util_linux.h

After following this thread for a while today I tried to update my chromium on openSUSE Leap 42.1 and I am getting the message:

#### YaST2 conflicts list - generated 2016-11-01 11:18:36 ####

chromium-54.0.2840.59-82.1.x86_64 obsoletes chromium-desktop-gnome provided by chromium-desktop-gnome-53.0.2785.143-79.2.x86_64

    [ ] remove lock to allow removal of chromium-desktop-gnome-53.0.2785.143-79.2.x86_64

    [ ] do not install chromium-54.0.2840.59-82.1.x86_64

#### YaST2 conflicts list END ###

Does that mean that v.54 has built-in support for gnome keyring or what?

Thanks Thomas for the help! With these CLs I expect the problem to be solved.

A note for the tester who verifies this: please make sure you understand how to reproduce this. It is tricky enough that it slipped past. I'm happy to provide clarifications.

Re comment #89

I'm not familiar with that particular tool, but I don't see anything related to keyring in the message. Keyring support in Chrome has existed for several years.

It is my impression that your problem is unrelated to this bug. Please keep this thread on topic. I recommend you first reach out to wherever you're getting the chromium distribution from.

Re #91

It is on topic. The package chromium-desktop-gnome is the one that has always been needed so far in order chromium to be able to work with gnome keyring. Hence my question: is it now the case that all functionality has been integrated it the chromium package (which makes the other one obsolete)? Before the recent changes related to this bug report and the intricacies of gnome keyring both package versions were always updated in-sync.

There are no changes to the different builds of Chrome that are the result of this bug. Also, the versions you posted are 53 and 54, and not 55, which is where this bug is fixed.

You should contact the third-party that builds and distributes Chromium to you, if you want to know why they changed the package and what that means. Google does not distribute Chromium builds as far as I know.

Will do. Thanks.

 Issue 655878  has been merged into this issue.

I have the same problem. It started after I deleted my entire Chrome directory (~/.config/google-chrome) to start with a clean state. Since then, everytime I log out from Linux and log in again and start Chrome, it shows the dialog "A change in your account requires you to sign in again" (that's sign in to Chrome).

 Issue 662668  has been merged into this issue.

today there was an update to version 55.0.2883.75. works fine for me :)

thanks for your work!

% uname -r
4.8.10-300.fc25.x86_64

% lsb_release -s -d
"Fedora release 25 (Twenty Five)"

% localectl
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: de-nodeadkeys
      X11 Layout: de
     X11 Variant: nodeadkeys

% google-chrome --version
Google Chrome 55.0.2883.75

% rpm -qa \*keyring\* \*seahorse\* \*libsecret\* | sort
gnome-keyring-3.20.0-1.fc25.x86_64
gnome-keyring-pam-3.20.0-1.fc25.x86_64
gnome-python2-gnomekeyring-2.32.0-24.fc25.x86_64
libgnome-keyring-3.12.0-7.fc25.x86_64
libsecret-0.18.5-2.fc25.x86_64
seahorse-3.20.0-1.fc25.x86_64
seahorse-nautilus-3.11.92-6.fc24.x86_64

Chromium 55.0.2883.75 in Antergos/Arch Linux (Kernel 4.8.11-1) seems to have fixed the issue for me, too. Thanks everyone! :)

Reinstalled gnome-keyring today. I've rebooted twice. The first time, Chrome prompted me to unlock the keyring. I did, and was still logged in.

Just now, I rebooted again, Chrome prompted to me to unlock, and sure enough was logged out of GitHub, TweetDeck, Google, etc. Everywhere.

And I have the "profile sync error" in the titlebar.

Version 57.0.2970.0 (Official Build) dev (64-bit) from the AUR package.

 Issue 384712  has been merged into this issue.