Reauthenticate the user before launching Smart Lock setup app.

chrome/browser/signin/easy_unlock_service.cc

Index: chrome/browser/signin/easy_unlock_service.cc
diff --git a/chrome/browser/signin/easy_unlock_service.cc b/chrome/browser/signin/easy_unlock_service.cc
index ad20ddedcad7e274d9e9b6aa8b1513db73d1cfc8..0cfa475c5900df140f6998ae0a1b69a3d85dc4d4 100644
--- a/chrome/browser/signin/easy_unlock_service.cc
+++ b/chrome/browser/signin/easy_unlock_service.cc
@@ -362,10 +362,6 @@ void EasyUnlockService::CheckCryptohomeKeysAndMaybeHardlock() {
     return;
   }
 
-  // No need to compare if a change is already recorded.
-  if (GetHardlockState() == EasyUnlockScreenlockStateHandler::PAIRING_CHANGED)
-    return;
-
   chromeos::EasyUnlockKeyManager* key_manager =
       chromeos::UserSessionManager::GetInstance()->GetEasyUnlockKeyManager();
   DCHECK(key_manager);
@@ -592,8 +588,12 @@ void EasyUnlockService::OnCryptohomeKeysFetchedForChecking(
   for (const auto& device_key_data : key_data_list)
     devices_in_cryptohome.insert(device_key_data.public_key);
 
-  if (paired_devices != devices_in_cryptohome ||
-      GetHardlockState() == EasyUnlockScreenlockStateHandler::NO_PAIRING) {
+  if (paired_devices == devices_in_cryptohome) {

[tbarzic, 2014/10/27 21:44:43]

I don't think this is the right thing to do in general case.
I'm particularly concerned about two cases:
1. Chrome OS public key is changed, which would change PSK (even though phone
public key stays the same).
2. User turns off easy unlock, and then easy unlock gets reenabled due to sync
(before user ever providing credentials to update cryptohome state) It is an
edge case, but still, I'm not too happy with introducing it :/

[xiyuan, 2014/10/28 20:38:03]

For 1, maybe we should consider using psk instead of phone key for the change
detection.

2 should be addressed too. We should clear the hardlock state somewhere else,
e.g. in EasyUnlockServiceRegular::OnKeysRefreshedForSetDevices.

[Tim Song, 2014/10/31 17:57:37]

For 1, I did as Xiyuan suggested and made the check based on the psk.

I'm not sure I understand 2, though. Turning off easy unlock should clear the
cryptohome keys. If new keys were ever synced, that would result in the
preference keys not matching the cryptohome keys, and give us the expected
behaviour.

[tbarzic, 2014/10/31 18:24:09]

cryptohome keys are actually cleared on the next user authentication (afaik, we
need user credentials for this too), so if we sync before that, the values in
user prefs and cryptohome would match (provided that the set of setup phones is
the same)

[Tim Song, 2014/11/01 03:16:52]

Okay that makes sense. I changed the hardlock state in EasyUnlockServiceRegular
instead and reverted this check back to what it was before.

+    if (GetHardlockState() != EasyUnlockScreenlockStateHandler::USER_HARDLOCK) {
+      SetHardlockStateForUser(user_id,
+                              EasyUnlockScreenlockStateHandler::NO_HARDLOCK);
+    }
+  } else {
     SetHardlockStateForUser(user_id,
                             EasyUnlockScreenlockStateHandler::PAIRING_CHANGED);
   }