Yes this is probably the result of my work.

Password manager (which is controlled by --password-store) is not the only component that uses OSCrypt (the component which now uses keyring). Unfortunately, OSCrypt does not observe the switch in 53.

The good news is that the fix is already there and coming with the next version. https://codereview.chromium.org/2159743002/

The bad news is that you'll then probably have to reset your Chrome profile, since switching from one password store to another (in your case from libsecret to basic) cannot happen without loss of data.

Apologies that you'll have to put up with this for 2 months.

I'm not sure I understand the implications of this. If I save passwords at present, is Chrome going to write them to libsecret instead of to my existing basic store? In M54, when the switch is again honored, are any passwords that I added in the meantime going to disappear? If sync is enabled, will they at least get restored after the profile reset?

(I'm also dismayed that the fix wasn't merged before this went out to stable channel, but maybe the bug wasn't known then.)

Passwords will continue to be stored in the same place. It is other components, which are using encryption and which will lose data when encryption switches back to "basic".

@vabr: Password manager in basic does not obfuscate with OSCrypt, correct?

That's probably not very reassuring, since the location where basic puts them is the profile, right next to the data you will lose. I'm not sure if you can reset selectively.

I would expect that passwords will be restored after you reset your profile. Again, maybe vabr@ can confirm that.

You are right that we were not aware of this bug before you reported it. The fix was introduced for different reasons at the time.

Indeed, password manager does not use OSCrypt for its Login Database encryption: components/password_manager/core/browser/login_database_posix.cc

About the main issue: if the keyring was never unlocked, how could have Chrome actually encrypted the profile data?

Sorry, I presumed that keyring was unlocked. If it is not unlocked, then OSCrypt defaults to the old behaviour (i.e. basic).

To the best of my knowledge, I've never unlocked this keyring and don't have anything stored in it (and even now, I'm just hitting the Cancel button on the dialog). Is there some way I can remove it entirely to go back to the basic store while using M53? I'd happy remove the keyring packages if that'd help, but dependencies. :-P

s/happy/happily/

(Does the fact that I'm not unlocking it mean that there's no risk of data loss or need to delete profiles later, and that this will just be a minor annoyance for one release when starting Chrome?)

I couldn't find an official option to get rid of it. If you want to kill it with fire, you can find the libsecret-1.so.0 library (probably /usr/lib/x86_64-linux-gnu/libsecret-1.so.0) and do something bad to it. Chrome will handle it, but I can't speak for other programs. Many things use it and some may take it for granted.

If you never unlock keyring, won't lose data because of this. If you ever did unlock it, the consequences would appear the next time you refuse.

Same here on openSUSE Leap 42.1  + KDE ... 

This this seems to be the only thing to suppress the keyring login prompt without breaking everything else:

sudo mv /usr/bin/gnome-keyring-daemon /usr/bin/gnome-keyring-daemon.disabled

 Issue 643351  has been merged into this issue.

Any chance a fix could be backmerged here? I've had several KDE users complain to me about being nagged by Gnome-keyring dialogs every time they start up Chrome; in one case the dialog apparently is about *creating* a default keyring (so clearly this user has never used gnome-keyring before). I can repro this on my own machine.

Six weeks between stable releases is a long time to wait if something is nagging you every day.

r406056 should fix both problems described in this bug:
1. --password-store being ignored
2. gnome-keyring prompts in KDE systems.

Can we merge it into 53? It is currently in M54 beta.

Before we approve merge to M53, Could you please confirm whether this change is well baked/verified in beta and safe to merge? Please note that M53 is very close to Stable launch and bar is VERY high, we take this change ONLY if it is critical and safe.

I must correct my previous statement. This change was in dev M54 for over one month. However, the code was further modified before reaching beta.

I can confirm that the change applies to M53 and is an appropriate fix. I cannot confirm that the change is verified in beta.

 Issue 644099  has been merged into this issue.

OK, based on update #18, change is well baked in Canary/Dev and it is an appropriate fix. Also it is a regression in M53. So approving merge to M53 branch 2785. Please merge before 3:00 PM PT, Tuesday (09/06) in order to make it to this week Stable cut. Thank you.

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

commit 1673c9e4ac994c620bc08a7ee9cd963515a26fb4
Author: Vaclav Brozek <vabr@chromium.org>
Date: Tue Sep 06 08:43:21 2016

Forward --password-store switch to os_crypt

Password manager uses a switch to allow the user to override the
auto-detection of the appropriate password store. OSCrypt should
respect this switch as well.

The switch value is read and passed to OSCrypt at a very early
point in Chrome's start, before any of OSCrypt's dependents
use it.

I also reworked OSCrypt's build to make it simpler for chrome to
deduce whether the linux implementation of OSCrypt will be used.
 - Previously, os_crypt_linux was used only if we also decided to
   link at least one linux backend. Otherwise we used os_crypt_posix.
 + Now, we always use the linux implementation for linux. If no
   KeyStorage is linked, the linux implementation defaults to the
   same behavior as for posix.

This CL is a fixed version of https://codereview.chromium.org/2118443002/

Note: old BUG was 602624, but the merge approval is at 643189.
BUG= 643189 

Review-Url: https://codereview.chromium.org/2159743002
Cr-Commit-Position: refs/heads/master@{#406056}
(cherry picked from commit 3ea4c69178fd68bcdc880bc2c83481e57e293403)

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

Cr-Commit-Position: refs/branch-heads/2785@{#826}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/chrome/browser/chrome_browser_main_linux.cc
[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/components/components_tests.gyp
[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/components/os_crypt.gypi
[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/components/os_crypt/BUILD.gn
[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/components/os_crypt/key_storage_linux.cc
[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/components/os_crypt/key_storage_linux.h
[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/components/os_crypt/os_crypt.h
[modify] https://crrev.com/1673c9e4ac994c620bc08a7ee9cd963515a26fb4/components/os_crypt/os_crypt_linux.cc

I checked go/betabuilders and did not see the merge in #21 adding any more breakage than present before.

After this week's update of stable, the issue should disappear. Would be awesome if some of the affected users could confirm here once that happens.

I'll test the update. What would be the exact version of this week's update of stable? 

 Retested the above issue on Ubuntu 14.04 with chrome version '55.0.2851.0' (branch version - 416559) by over installing it over M54 build - 54.0.2840.8 but still keyring prompt is seen on every chrome launch.

Attach is the video for the same.

@cfroussios: Hey, can you please check the video and let me know if I missed something.

Thank you!

If you are in a gnome environment (e.g. Ubuntu), it is the intended behaviour that keyring will be opened (and you may get prompted). If you don't want to use keyring, then you must use --password-store=basic.

It wasn't clear in the video whether you are using the flag. Can you test whether you are getting prompted after using the switch?

I have verified that on corp machine when I launch Chrome Canary(55.0.2851.0) with " --password-store=basic" I don't see the any entries for "Chrome Safe Storage" getting created under seahorse, but the same when I launch Chrome normally they I see that "Chrome Safe Storage" is getting created under seahorse(Based on offline chat with cfroussios@ we are seeing expected behavior).

At #23 -- thanks for the offer! The version needs to be 53.0.2785.X for X >= 98. Based on #20, I guess you should be able to see it approximately next week.

Verified the fix on Chrome version 53.0.2785.101 on ubuntu and the steps followed as mentioned in comment#27

steps followed :
1. Install Chrome  53.0.2785.101 
2. Launch Chrome using " google-chrome-stable --password-store=basic"
3. Open seahorse 

Observed behaviour :
Haven't seen any entry for "Chrome Safe Storage" under seahorse.

Thanks for the verification! The absence of "Chrome Safe Storage" in the keyring should imply that Chrome does not attempt to write in the keyring. To verify exactly the reported issue, one should actually lock the keyring, then start Chrome and Chrome should not prompt for unlocking the keyring. If anybody gets a chance to check that, please report. I'll close the issue based on #29, but will still get comments. (If you cannot comment, feel free to mail vabr@chromium.org directly.)
Thanks!

hello
opensuse 13.1 x86_64

no more problem with this today update Version 53.0.2785.101 (64-bit)

thanks

Tested  53.0.2785.101 on openSUSE Leap 42.1 - no more keyring login prompts, even with /usr/bin/gnome-keyring-daemon back in place.

Thank you for a prompt fix.

Thanks everybody for help and verification, and cfroussios@ for the fix!

 Issue 645809  has been merged into this issue.

I think there is still a bug (or regression) here, in that a user who has saving passwords disabled is prompted to unlock a keyring (or make it), unless the parameter is passed.

This is also discussed in a separate (now obsolete, I think) bug.

https://bugs.chromium.org/p/chromium/issues/detail?id=369164#c17

Asking to unlock the keyring even if the password manager is off is an expected change: Chrome now uses the keyring to provide data encryption, which is used by other components than just password manager. The change is improving the security of the data, and the need to have the keyring enabled is the price to pay for. We are currently discussion with our product manager if it would make sense to expose a setting with the same function as the command-line flag and test its behaviour, or whether to leave this as the untested command-line flag.

For the past several weeks since an upgrade, I also experienced this bug.

Version 53.0.2785.143, running on Ubuntu 16.04 (64-bit).

I'm using stable release from Ubuntu repositories (a.k.a. no PPA).

Although not ideal, I have verified that starting Chromium with the "--password-store=basic" flag suppresses the key ring prompt.

Requesting keyring access on startup is the correct behaviour from version 53 onward.

If you are annoyed by keyring prompts, I recommend setting keyring to unlock automatically on login. Using the --password-store=basic flag is discouraged for non-development purposes. Its effect is that your passwords will be completely unecrypted on your disk. Additionally, it is unsupported and may break whenever.

> I recommend setting keyring to unlock automatically on login.

Which doesn't apply when you have auto-login configured.

Personally I think Google needs to sell this feature better, particularly for those users who don't save passwords.

I think part of the problem here is that it is unclear why Chrome needs to unlock the keyring, especially because it did not do so before, and because it happens at a time where -- at least to the user -- no sensitive data is handled. There is no password storage going on, no opening pages yet, so no cookies. The situation is similar to the new permission model in Android, where getting prompted to allow a specific permission can be very confusing in a situation where it is unclear what the permission is required for. The solution there is to make the app tell the user “We’re now going to ask for this permission, which we need in order to do ...” Chrome could do something similar.

Apart from this, there is a usability issue with the current implementation: the unlock prompt pops up after typing the first character in the omnibar. This means that I type the remainder of the url that I intended to type into the unlock prompt, leaving me both with no url in the omnibar, and wrong input in the unlock prompt.

Now I think about this, could it be because of the speculative loading logic? So when I begin typing a url, Chrome actually does start loading a page and so it needs to decrypt something? (By the way, it is still not clear to me what “data encryption, which is used by other components than just password manager” means. Does that include cookie storage? Browsing history used in omnibar suggestions?) If that is the case, I think simply disabling speculative loading if the keyring has not been unlocked could be a big improvement in usability. The time saved by speculative loading is currently nullified by me having to backspace when the unlock dialog suddenly pops up while I am typing the url.

> Using the --password-store=basic flag is discouraged for non-development purposes. Its effect is that your passwords will be completely unecrypted on your disk.

Note that when full disk encryption is used, this is not a concern.

Chrome encrypts your secure cookies (https://en.wikipedia.org/wiki/HTTP_cookie#Secure_cookie) on disk. Typing into the omnibox triggers the autocomplete feature (unless disabled in settings) which uses an HTTPS connection and secure cookies.

I've filed crbug.com/658348 for the usability issue described in comment #40. Thank you for reporting.