Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(8)

Side by Side Diff: sync/engine/apply_control_data_updates.cc

Issue 10559104: sync: Process 'control' data separately (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: Rename, cleanup, fix tests Created 8 years, 6 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch | Annotate | Revision Log
OLDNEW
(Empty)
1 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style license that can be
3 // found in the LICENSE file.
4
5 #include "sync/engine/apply_control_data_updates.h"
6
7 #include "base/metrics/histogram.h"
8 #include "sync/engine/conflict_resolver.h"
9 #include "sync/engine/nigori_util.h"
10 #include "sync/engine/syncer_util.h"
11 #include "sync/syncable/directory.h"
12 #include "sync/syncable/mutable_entry.h"
13 #include "sync/syncable/write_transaction.h"
14 #include "sync/util/cryptographer.h"
15
16 using syncable::GET_BY_SERVER_TAG;
17 using syncable::IS_UNAPPLIED_UPDATE;
18 using syncable::IS_UNSYNCED;
19 using syncable::NIGORI;
20 using syncable::SERVER_SPECIFICS;
21 using syncable::SPECIFICS;
22 using syncable::SYNCER;
23
24 namespace csync {
25
26 void ApplyControlDataUpdates(syncable::Directory* dir) {
27 syncable::WriteTransaction trans(FROM_HERE, SYNCER, dir);
28 ApplyNigoriUpdates(&trans, dir->GetCryptographer(&trans));
29 }
30
31 void ApplyNigoriUpdates(syncable::WriteTransaction* trans,
32 Cryptographer* cryptographer) {
33 syncable::MutableEntry nigori_node(trans, GET_BY_SERVER_TAG,
34 ModelTypeToRootTag(NIGORI));
35
36 // Mainly for unit tests. We should have a Nigori node by this point.
37 if (!nigori_node.good()) {
38 return;
39 }
40
41 // We always update the cryptographer with the server's nigori node,
42 // even if we have a locally modified nigori node (we manually merge nigori
43 // data in the conflict resolver in that case). This handles the case where
44 // two clients both set a different passphrase. The second client to attempt
45 // to commit will go into a state of having pending keys, unioned the set of
46 // encrypted types, and eventually re-encrypt everything with the passphrase
47 // of the first client and commit the set of merged encryption keys. Until the
48 // second client provides the pending passphrase, the cryptographer will
49 // preserve the encryption keys based on the local passphrase, while the
50 // nigori node will preserve the server encryption keys.
51 //
52 // If non-encryption changes are made to the nigori node, they will be
53 // lost as part of conflict resolution. This is intended, as we place a higher
54 // priority on preserving the server's passphrase change to preserving local
55 // non-encryption changes. Next time the non-encryption changes are made to
56 // the nigori node (e.g. on restart), they will commit without issue.
57 if (nigori_node.Get(IS_UNAPPLIED_UPDATE)) {
58 const sync_pb::NigoriSpecifics& nigori =
59 nigori_node.Get(SERVER_SPECIFICS).nigori();
60 cryptographer->Update(nigori);
61
62 // Make sure any unsynced changes are properly encrypted as necessary.
63 // We only perform this if the cryptographer is ready. If not, these are
64 // re-encrypted at SetDecryptionPassphrase time (via ReEncryptEverything).
65 // This logic covers the case where the nigori update marked new datatypes
66 // for encryption, but didn't change the passphrase.
67 if (cryptographer->is_ready()) {
68 // Note that we don't bother to encrypt any data for which IS_UNSYNCED
69 // == false here. The machine that turned on encryption should know about
70 // and re-encrypt all synced data. It's possible it could get interrupted
71 // during this process, but we currently reencrypt everything at startup
72 // as well, so as soon as a client is restarted with this datatype marked
73 // for encryption, all the data should be updated as necessary.
74
75 // If this fails, something is wrong with the cryptographer, but there's
76 // nothing we can do about it here.
77 DVLOG(1) << "Received new nigori, encrypting unsynced changes.";
78 syncable::ProcessUnsyncedChangesForEncryption(trans, cryptographer);
79 }
80
81 if (!nigori_node.Get(IS_UNSYNCED)) { // Update only.
82 SyncerUtil::UpdateLocalDataFromServerData(trans, &nigori_node);
83 } else { // Conflict.
84 // Create a new set of specifics based on the server specifics (which
85 // preserves their encryption keys).
86 sync_pb::EntitySpecifics specifics = nigori_node.Get(SERVER_SPECIFICS);
87 sync_pb::NigoriSpecifics* server_nigori = specifics.mutable_nigori();
88 // Store the merged set of encrypted types (cryptographer->Update(..) will
89 // have merged the local types already).
90 cryptographer->UpdateNigoriFromEncryptedTypes(server_nigori);
91 // The cryptographer has the both the local and remote encryption keys
92 // (added at cryptographer->Update(..) time).
93 // If the cryptographer is ready, then it already merged both sets of keys
94 // and we can store them back in. In that case, the remote key was already
95 // part of the local keybag, so we preserve the local key as the default
96 // (including whether it's an explicit key).
97 // If the cryptographer is not ready, then the user will have to provide
98 // the passphrase to decrypt the pending keys. When they do so, the
99 // SetDecryptionPassphrase code will act based on whether the server
100 // update has an explicit passphrase or not.
101 // - If the server had an explicit passphrase, that explicit passphrase
102 // will be preserved as the default encryption key.
103 // - If the server did not have an explicit passphrase, we assume the
104 // local passphrase is the most up to date and preserve the local
105 // default encryption key marked as an implicit passphrase.
106 // This works fine except for the case where we had locally set an
107 // explicit passphrase. In that case the nigori node will have the default
108 // key based on the local explicit passphassphrase, but will not have it
109 // marked as explicit. To fix this we'd have to track whether we have a
110 // explicit passphrase or not separate from the nigori, which would
111 // introduce even more complexity, so we leave it up to the user to reset
112 // that passphrase as an explicit one via settings. The goal here is to
113 // ensure both sets of encryption keys are preserved.
114 if (cryptographer->is_ready()) {
115 cryptographer->GetKeys(server_nigori->mutable_encrypted());
116 server_nigori->set_using_explicit_passphrase(
117 nigori_node.Get(SPECIFICS).nigori().
118 using_explicit_passphrase());
119 }
120 // We deliberately leave the server's device information. This client will
121 // add its own device information on restart.
122 nigori_node.Put(SPECIFICS, specifics);
123 DVLOG(1) << "Resolving simple conflict, merging nigori nodes: "
124 << nigori_node;
125
126 SyncerUtil::OverwriteServerChanges(&nigori_node);
127
128 UMA_HISTOGRAM_ENUMERATION("Sync.ResolveSimpleConflict",
129 ConflictResolver::NIGORI_MERGE,
130 ConflictResolver::CONFLICT_RESOLUTION_SIZE);
131 }
132 }
133 }
134
135 } // namespace csync
OLDNEW
« no previous file with comments | « sync/engine/apply_control_data_updates.h ('k') | sync/engine/apply_control_data_updates_unittest.cc » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698