Reauthenticate the user before launching Smart Lock setup app.

chrome/browser/signin/easy_unlock_service.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/signin/easy_unlock_service.h"
 
 #include "base/bind.h"
 #include "base/command_line.h"
 #include "base/logging.h"
 #include "base/metrics/field_trial.h"
@@ skipping 344 matching lines @@
     chromeos::EasyUnlockKeyManager::RemoteDeviceListToDeviceDataList(
         *device_list, &parsed_paired);
     for (const auto& device_key_data : parsed_paired)
       paired_devices.insert(device_key_data.public_key);
   }
   if (paired_devices.empty()) {
     SetHardlockState(EasyUnlockScreenlockStateHandler::NO_PAIRING);
     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);
 
   key_manager->GetDeviceDataList(
       chromeos::UserContext(user_id),
       base::Bind(&EasyUnlockService::OnCryptohomeKeysFetchedForChecking,
                  weak_ptr_factory_.GetWeakPtr(),
                  user_id,
                  paired_devices));
@@ skipping 206 matching lines @@
   if (!success) {
     SetHardlockStateForUser(user_id,
                             EasyUnlockScreenlockStateHandler::NO_PAIRING);
     return;
   }
 
   std::set<std::string> devices_in_cryptohome;
   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);
   }
 }
 #endif
 
 void EasyUnlockService::PrepareForSuspend() {
   DisableAppIfLoaded();
   if (screenlock_state_handler_ && screenlock_state_handler_->IsActive()) {
     UpdateScreenlockState(
         EasyUnlockScreenlockStateHandler::STATE_BLUETOOTH_CONNECTING);
   }
 }