Fix getPairedClients for un-elevated native messaging process.

remoting/protocol/pairing_registry.cc

Index: remoting/protocol/pairing_registry.cc
diff --git a/remoting/protocol/pairing_registry.cc b/remoting/protocol/pairing_registry.cc
index e33b59d059df2ee54362b395e78827d3ccd22881..edf085cd090ad331d3465fe135aa366f881cab74 100644
--- a/remoting/protocol/pairing_registry.cc
+++ b/remoting/protocol/pairing_registry.cc
@@ -90,7 +90,9 @@ bool PairingRegistry::Pairing::operator==(const Pairing& other) const {
 }
 
 bool PairingRegistry::Pairing::is_valid() const {
-  return !client_id_.empty() && !shared_secret_.empty();
+  // |shared_secret_| is optional. It will be empty on Windows because the
+  // privileged registry key can only be read in the elevated host process.

[Jamie, 2014/02/22 00:28:39]

Could we fix this by setting a dummy value for the shared secret on Windows? I
would prefer that we don't change the validity semantics for a Pairing to match
a particular platform's implementation of the storage layer.

+  return !client_id_.empty();
 }
 
 PairingRegistry::PairingRegistry(