This is either a feature bug (i.e. not security), or WAI.  dvadym - Can you comment/close/reassign as appropriate?  Thanks.

+rsleevi@ per wfh@.

Thanks for the report. Could you please follow  http://crbug.com/583263#c9  and check whether your instance of Chrome does not use the profile SQL database instead of the Keyring?

I tested on my machine (GNU/Linux with Cinnamon, Chrome 51.0.2704.84 (Official Build) (64-bit)) that when I lock the keyring, passwords disappear from chrome://settings/passwords, and when I unlock it (and refresh the settings), they appear again.

A side note: we plan to migrate Chrome from using the Keyring, bug 571003, so in the future, all instances will use the profile login database and will not depend on the keyring.

wfh: Not sure why you suggested me. I haven't the slightest for the password management code (only how we use the OSCrypt functionality, but AIUI, the password manager doesn't do that)

Yes when I lock and unlock keyring it works as you described. 

So actually what happened is I changed my keyring password to be different than my login password, and what chrome did on boot is it switched to using the sqllite database and quering that table revealed all my passwords.  

Once I switched the keyring password back to be the same as login password, the sqllite database disappeared and it started using keyring again. So somehow chrome is able to get the passwords from somewhere and put them into the sqllite database? Oh right, probably from the cloud?

Thank you for providing more feedback. Adding requester "vabr@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

Thanks for the clarification in #7.

It is unfortunate that Chrome would fall back to the login database without noticing the user. This would definitely be something we need to fix, were it not for getting rid of the whole Keyring backend for storing passwords (bug 571003). However, even without storing passwords in the Keyring we will use the Keyring to store the passphrase for encrypting the passwords in the database. We must make sure that we won't silently fall back to not encrypting the passwords if the keyring is temporarily inaccessible. I filed bug 619485 to track that.

As for Chrome switching back to the keyring: that should only work if you sync your passwords through Chrome Sync. If you don't, there is no local migration mechanism which would do that.

While this definitely is an issue, the quickest way forward for us is still to finish the transition in bug 571003 and prevent the reincarnation of this issue in bug 619485. Fixing the current state would delay the former, which has also other benefits. Therefore I'm marking this as WontFix.