Hi Ulan, this sounds rather strange! I'll be happy to have a look at your machine next week.

Ulan, could you check if Chrome has some interesting logs about PasswordStore start-up?

Please do the following:
- Go to chrome://version and copy Executable Path
- Quit Chrome (Cmd+Q, not just closing a window)
- Launch Chrome via command line with --enable-logging --v=1
- Open a page where you expect to have a password filled
- Close Chrome and go to a parent directory of "Profile Path"
- Share chrome_debug.log with me (by e-mail)


Just for the record, what I saw on Ulan's machine so far was that Chrome had trouble accessing the local storage (about:sync-internals reported a failure merging the passwords, filling does not work, about:settings/passwords are empty), but it seems to be migrated off Keychain successfully (see  http://crbug.com/466638#c45  for how to check that) and inspecting the Login DB ( http://crbug.com/583263#c9 ) showed the credentials present.

I sent the log file by email.

Thanks, Ulan!

In the logs there were two interesting messages:

[52206:57355:0502/135902:ERROR:password_syncable_service.cc(162)] Passwords datatype error was encountered: Failed to get passwords from store.

[52206:57355:0502/135928:ERROR:connection.cc(1919)] Passwords sqlite error 2067, errno 0: UNIQUE constraint failed: logins.origin_url, logins.username_element, logins.username_value, logins.password_element, logins.signon_realm, sql: INSERT INTO logins (...) VALUES (...)


The first means that Chrome was not possible to retrieve all your stored passwords through PasswordStore. The latter should be a result of you trying to accept the "save password" offer on a page where you managed to save a password in the past -- Chrome is now unable to understand that it is saved already, but on the low level, the database refuses to create a duplicate entry.

What is strange is the absence of initialisation failures of the password store. To help us understand more, could you please repeat #2 (including collecting the logs) but this time for a password site where you never saved a password before? You can use the second-last form on https://rsolomakhin.github.io/autofill/ (any garbage data will do, it's just a test page) if you never used that, or let me know if you need another URL.

Thanks!

I didn't capture the log correctly. Could you please give another url?

https://9bf5d6a9ae58c0976f64da8a482db42e19365982.googledrive.com/host/0B4ln_TN4AjcNbzd3RDNQYlJRVG8

Thanks! Sent you email.

Looking into the potential causes of the
"Passwords datatype error was encountered: Failed to get passwords from store."
message which also appears in the logs from #7, one is failing decryption of the passwords.

Ulan, did you change your OS password or made the Keychain inaccessible before observing this issue?

Open the Keychain app. Find "Chrome Safe Storage" there. What is the modification date there? Which apps are listed in the access list?

Issue 618946 has been merged into this issue.

I'm also getting this issue. Answering #9 below:
- Oct 26 2015
- Google Chrome.app

Sorry, missed this thread.

The date and app in keychain:
- Feb 18, 2016.
- Google Chrome.

Is it about the time you started observing the bug?

Yes, most likely. I don't remember exactly.

Vasilii, is there something we can have a look at to check if the access list for Keychain is messed up for Chrome? We could check it with ulan's help on ulan's computer in person.

There seems to be one more similar case: http://crbug.com/621595

It would be good if we figure out how can the user get into this state. Vasilii, do you have a hypothesis how that could happen?

There are at least two workarounds. Both clear the password store and make it work again:
- Delete "Chrome Safe Storage" password from the Keychain while Chrome is closed.  Start syncing with a fresh profile and drop the old one.
- Remove '<Profile Path>\Login Data' while Chrome is closed. Profile path can be located in chrome://version/.

A question to the reporters. Do you use different Chrome channels simultaneously (e.g. Stable and Canary)?

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

commit 03a31a078bea4b2f229ef1e6c7749239caa1910e
Author: vabr <vabr@chromium.org>
Date: Mon Jun 27 15:25:56 2016

Log error if decryption fails in LoginDatabase

BUG= 607882 
R=vasilii@chromium.org

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

[modify] https://crrev.com/03a31a078bea4b2f229ef1e6c7749239caa1910e/components/password_manager/core/browser/login_database.cc

Issue 621595 has been merged into this issue.

The current hypothesis here is that the Keychain entry used by KeychainPassword::GetPassword gets reset at some point. Chrome can continue saving and filling passwords created after that point, but older passwords are inaccessible, which breaks filling of them and also syncing of all passwords. The cause of the Keychain entry being reset is unclear. It could be anything including:
 * Two versions of Chrome (e.g., Canary vs. Stable) clashing (as they try to use the same entry).
 * Other program or user affecting the Keychain.
 * In particular, Keychain being cleared after password reset.
 * Potential bug in the Keychain.
 * etc.

Out of the list above, the first item would be a bug in Chrome, the rest is beyond Chrome's control. Until we know a concrete reason why the Keychain entry was deleted, we cannot fix it, though, so I'll close this report (and am happy to reopen upon a well documented failure or even reproduction steps).

What we can do, though, is make the work-around automatic. I filed  bug 624781  for it.

Thank you for investigating and filing  bug 624781 !

Small comment regarding 
"Chrome can continue saving and filling passwords created after that point"
in my case Chrome was not able to save (or to fill) new passwords. The password list was always empty. This was the main reason why I filed the bug, otherwise I wouldn't event notice the issue :)

Note for those who also have the same problem: I worked around the issue by clearing the Chrome profile directory.

Thanks for the comment, ulan@. Right, I forgot that Chrome failed to save password even on pages where none were stored previously. I'll need to have a deeper look to understand that properly.

I looked at the code and played with it a bit more: I selectively broke LoginDatabase::DecryptedString to fail for older passwords, and I think I'm doing something wrong. Sync is not failing with that, but the broken credential is just ignored. Also, I played with this on Linux for simplicity, not on Mac, which might also confused things.

In summary, I am no longer sure what is the correct hypothesis behind what ulan@ observes. I might try to check this out on Mac when I find more time.

Right, so now I tried with Mac, two scenarios:

For both of them I used Chrome with sync, and had 1 password stored for https://rsolomakhin.github.io/autofill/ and none for http://2.chromium-test1.appspot.com/testing/psl-matching/login .

Case "deleted entry":

(1) When Chrome is closed, open the Keychain and delete "Chrome Safe Storage".
(2) Start Chrome, try to save a password at https://rsolomakhin.github.io/autofill .
(3) Try to save a password at http://2.chromium-test1.appspot.com/testing/psl-matching/login .

Observed:
After step (2), Chrome prompted to save the password. Upon clicking on Save, it likely saved it, but could not fill it or display it in settings.
After step (3), Chrome prompted to save the password. Upon clicking on Save, it did save it and was able to fill it in the page. However, it did not show up in about:settings/passwords (just blacklisted entries were shown).
(Also, because "Chrome Safe Storage" was used to secure the sync credentials, I had to re-enter that to keep sync going.)

The explanation for this is: no non-blacklisted passwords are shown in the settings, because when Chrome asks the PasswordStore to provide a list, at least one of the passwords to be provided fails to be decrypted. The same explains why filling does not work on the URL from point (2) -- password manager for that page cannot obtain all passwords stored for it and gives up completely. Because there had been no passwords stored for the URL of (3), filling the newly created worked.

To fix that situation, I deleted the Login\ Data file in the profile directory (see about:version). That allowed Chrome to repopulate the DB with the synced passwords and encrypt them with the reset "Chrome Safe Storage" password. However, I lost the newly created passwords in step (2) and (3), as they could not be synced (password sync being broken by the presence of non-decryptable passwords). If I wanted to save those, I would have to edit the Login\ Data with sqlite3 or similar tool and only remove the old passwords.


Case "locked Keychain"

(1) When Chrome is closed, lock the Keychain.
(2) Start Chrome, refuse to unlock the Keychain, try to save a password at https://rsolomakhin.github.io/autofill .
(3) Try to save a password at http://2.chromium-test1.appspot.com/testing/psl-matching/login .
(4) Unlock the Keychain.

Observed: Once the Keychain is locked, Chrome gives up permanently. "Gives up" means that although it offers to save the passwords in steps (2) and (3), it can neither fill them, nor list them in the settings. "Permanently" means that even after unlocking in step (4), Chrome still fails in the same way. It only resumes password manager function after a restart.


So in addition to  bug 624781  which deals with helping the user to bypass the manual recovery of case "deleted entry", I filed bug 625149 to deal with the confusing UI offering saving passwords when it is not possible.