Don't upload extension IDs in the cloud policy protocol.

chrome/browser/policy/test/policy_testserver.py

Index: chrome/browser/policy/test/policy_testserver.py
diff --git a/chrome/browser/policy/test/policy_testserver.py b/chrome/browser/policy/test/policy_testserver.py
index 13b98f97ae27f54106f1726095a26aa721874be8..8998d7fd77419db7c7aaa553d11fd5a57546ca74 100644
--- a/chrome/browser/policy/test/policy_testserver.py
+++ b/chrome/browser/policy/test/policy_testserver.py
@@ -57,6 +57,7 @@ Example:
 import base64
 import BaseHTTPServer
 import cgi
+import glob
 import google.protobuf.text_format
 import hashlib
 import logging
@@ -463,6 +464,22 @@ class PolicyRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
         fetch_response.error_code = 400
         fetch_response.error_message = 'Invalid policy_type'
 
+    # Send additional PolicyFetchResponses for each extension that has
+    # configuration data, if the main request had a single user policy request.
+    if (len(msg.policy_request.request) == 1 and
+        msg.policy_request.request[0].policy_type in ('google/chromeos/user',
+                                                      'google/chrome/user')):

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

Wouldn't the correct implementation be to check whether *any* of the incoming
requests was for user policy?

[Joao da Silva, 2014/04/24 13:22:24]

I'm not sure. Since we don't send PolicyFetchRequests for extension policy, we
use the signing parameters from the user PolicyFetchRequest. If there is more
than one then which one triggers the fetch of policy for extensions?

Alternatively, we could do this for each user PolicyFetchRequest. In that case
the order of the responses will be significant.

I'd rather not make any assumptions about that at this stage, since we're still
in a simple world where there's 1 user PolicyFetchRequest per request :-)

[Mattias Nissler (ping if slow), 2014/04/24 13:38:25]

IIUC, the only parameter you rely on from the policy fetch is the signature
type, correct? Another variant here could be to send an explicit policy fetch
request for google/chrome/extension/*. Doing so would accomplish to goals: (1)
We signal that we actually want extension policy blobs so the server doesn't
have to send them if they aren't requested and (2) we can specify the parameters
for the response, such as signature type. I acknowledge that this would be
another (minor) protocol change. Ignoring any other factors, do you think that's
a better approach from a technical perspective?

+      ids = self.server.ListMatchingComponents('google/chrome/extension')
+      for settings_entity_id in ids:
+        fake_request = dm.PolicyFetchRequest()
+        # Copy the user policy request, to trigger the same signature type
+        # in the response.

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

Regarding signatures, have you thought about what the right behavior is
regarding key rotations? I suspect we should just not perform any rotations for
extension policy blobs. Does it make sense to implement that here? If not -
please add a comment explaining what features of ProcessCloudPolicy we may get
but don't actually need.

[Joao da Silva, 2014/04/24 13:22:24]

Correct, we don't do rotations for extension policy blobs. These blobs are
verified with the same key as the main user policy blob; if that key is rotated
for the user policy blob that it is automatically rotated for extension policy
blobs too.

For completeness, here is what happens: when the server sends down a user policy
blob with a new key it should also send down the extension policy blobs signed
with the new key. The component-policy code reacts when the user
CloudPolicyStore is updated (indicating that the rotation was successful), and
then picks up the new extension policy blobs and caches them. However, the
remote policy data is not fetched again, since their hashes should still be the
same.

I've updated the code to just remove any fields related to key updates from
these responses.

[Mattias Nissler (ping if slow), 2014/04/24 13:38:25]

Ah, so this was a bit surprising to me - we do request user policy to be signed
with the old key, but extension policy comes back in the reply with the new key.
I guess that makes sense though as you should have the extension policy blobs
always signed with the *current* (as determined by the server) user policy key.
 

+        fake_request.CopyFrom(msg.policy_request.request[0])
+        fake_request.policy_type = 'google/chrome/extension'
+        fake_request.settings_entity_id = settings_entity_id
+        fetch_response = response.policy_response.response.add()
+        self.ProcessCloudPolicy(fake_request, token_info, fetch_response)
+
     return (200, response)
 
   def ProcessAutoEnrollment(self, msg):
@@ -1056,6 +1073,22 @@ class PolicyTestServer(testserver_base.BrokenPipeHandlerMixIn,
     return os.path.join(self.data_dir or '',
                         'policy_%s' % sanitized_policy_selector)
 
+  def ListMatchingComponents(self, policy_type):
+    """Returns a list of settings entity id that have a configuration file.

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

IDs (consistent with spelling below)

[Joao da Silva, 2014/04/24 13:22:24]

Done.

+
+    Args:
+      policy_type: the policy type to look for. Only settings entity IDs for
+      file selectors that match this policy_type will be returned.
+
+    Returns:
+      A list of settings entity ID for the given |policy_type| that have a

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

IDs

[Joao da Silva, 2014/04/24 13:22:24]

Done.

+      configuration file in this server (either as a .bin, .txt or .data file).
+    """
+    base_name = self.GetBaseFilename(policy_type)
+    files = glob.glob('%s_*.*' % base_name)
+    len_base_name = len(base_name) + 1
+    return [ x[len_base_name:x.rfind('.')] for x in files ]

[Mattias Nissler (ping if slow), 2014/04/24 12:20:36]

s/x/file/

[Joao da Silva, 2014/04/24 13:22:24]

Done.

+
   def ReadPolicyFromDataDir(self, policy_selector, proto_message):
     """Tries to read policy payload from a file in the data directory.