Closed
Bug 709323
Opened 13 years ago
Closed 13 years ago
Handle key changes in info/collections
Categories
(Firefox for Android Graveyard :: Android Sync, defect, P1)
Tracking
(firefox14 fixed, blocking-fennec1.0 +)
VERIFIED
FIXED
mozilla15
People
(Reporter: ally, Assigned: nalexander)
References
()
Details
(Whiteboard: [qa+])
Attachments
(1 file)
(deleted),
patch
|
mfinkle
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
No description provided.
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → rnewman
Updated•13 years ago
|
tracking-fennec: --- → ?
Updated•13 years ago
|
tracking-fennec: ? → +
Assignee | ||
Updated•13 years ago
|
Assignee: rnewman → nalexander
Reporter | ||
Updated•13 years ago
|
tracking-fennec: + → ---
blocking-fennec1.0: --- → +
Assignee | ||
Comment 2•13 years ago
|
||
Bug 709324 implemented caching crypto/keys and testing info/collections to see if we need to re-fetch. Is that what this ticket is? Or is this to handle the case where a client generates a new collection key, updates the server with the new key, and we need to do something other than just "get new crypto/keys and sync as usual"?
Comment 3•13 years ago
|
||
This bug is: if we see keys have changed, and we download them and find that they're different, what do we do? The answer should be to do something similar to desktop, ensuring consistency. That is, if keys have changed, we need to make sure that all the data on the server is encrypted with those keys (on a per-collection basis). This is, IIRC, handled by wiping the server when we change keys, and handling *that* correctly.
Assignee | ||
Comment 5•13 years ago
|
||
Superceded by https://github.com/mozilla-services/android-sync/pull/166
Comment 6•13 years ago
|
||
What exactly is this bug for? Can we get a detailed description? Why do we need it? Really strange seeing a blocker with no content.
Assignee | ||
Comment 7•13 years ago
|
||
(In reply to Damon Sicore (:damons) from comment #6) > What exactly is this bug for? Can we get a detailed description? Why do we > need it? Really strange seeing a blocker with no content. I think https://bugzilla.mozilla.org/show_bug.cgi?id=709323#c3 is pretty clear, but let me add that we need this ticket to be a feature complete sync client that can continue operating when another client changes a collection key or when the server is in an illegal/partially initialized state and needs to be reset.
Comment 8•13 years ago
|
||
(In reply to Nick Alexander :nalexander from comment #7) > (In reply to Damon Sicore (:damons) from comment #6) > > What exactly is this bug for? Can we get a detailed description? Why do we > > need it? Really strange seeing a blocker with no content. > > I think https://bugzilla.mozilla.org/show_bug.cgi?id=709323#c3 is pretty > clear, but let me add that we need this ticket to be a feature complete sync Firefox on Android is in trouble if we don't already have a feature complete sync *right now*. Is the current list of Fennec blockers *THE* list of features that must be implemented for a feature complete sync that is required for fennec to ship? > client that can continue operating when another client changes a collection > key or when the server is in an illegal/partially initialized state and > needs to be reset.
Comment 9•13 years ago
|
||
(In reply to Damon Sicore (:damons) from comment #8) > Firefox on Android is in trouble if we don't already have a feature complete > sync *right now*. The target until this point has been feature complete and data integrity for the common case. That was explicitly called out to me as the goal for beta readiness, and we are at that point (modulo one outstanding beta blocker, of course). We don't support creating a new Sync account, choosing what to sync, or a multitude of other things that you could call "feature complete". (Those have all been explicit tradeoffs, because we've attempted to compress twelve months of work into four. If we wanted to be feature complete and polished by release, we should have started in August, rather than me burning out over Christmas to get a MSU working.) "The common case" also excludes this set of protocol scenarios: when the user is reassigned to a new node, their keys change on the server, or they otherwise encounter a server state that isn't "business as usual". Again, that was an explicit tradeoff for beta readiness, trading demoability for robustness. I (and the mobile drivers agree) that correctly handling the full set of server situations is a requirement for release, because enough users will hit those situations that we have to address them, and the consequences are unknown and probably bad. This should not come as a surprise to anyone who's been following along, because I've been quite vocal about these things since January. I have raised concerns about robustness and completeness prior to initial Aurora uplift, and mentioned it during Beta expectation setting. We have simply run out of phases to push this back to, so now we've got a few release blockers. > Is the current list of Fennec blockers *THE* list of features that must be > implemented for a feature complete sync that is required for fennec to ship? I will be happy releasing with Bug 745430, Bug 745431, Bug 713542, and Bug 714304 (which can slip at the cost of degraded user experience, but is a small task that we have free hands to do), which is why I have argued for those bugs to be release blockers. It won't be anywhere near perfect, but that's what I'm told a 1.0 is for.
Assignee | ||
Updated•13 years ago
|
Whiteboard: [patch waiting]
Reporter | ||
Updated•13 years ago
|
Whiteboard: [patch waiting] → [needs review :rnewman]
Comment 10•13 years ago
|
||
Last iteration through the review cycle.
Status: NEW → ASSIGNED
Whiteboard: [needs review :rnewman] → [waiting for final revised patch]
Assignee | ||
Updated•13 years ago
|
Whiteboard: [waiting for final revised patch] → [needs review :rnewman]
Comment 11•13 years ago
|
||
Reviewed and queued to land once it can be tested with other work as part of Bug 745430, Bug 745431. See <https://bugzilla.mozilla.org/show_bug.cgi?id=709321#c8> for testing tips.
Whiteboard: [needs review :rnewman] → [waiting for merge][qa+]
Comment 12•13 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/7ae35d533711 Let's plan on uplifting this along with the rest of Bug 745430/Bug 745431.
Whiteboard: [waiting for merge][qa+] → [qa+]
Target Milestone: --- → mozilla15
Comment 13•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/7ae35d533711
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 14•13 years ago
|
||
Sync team: Definitely want to uplift to beta, but not during the first one. We are considering uplifting 709321/323 all together with other dependencies of 745430/431.
Whiteboard: [qa+] → [qa+][want uplift during betaN, but not right now]
Reporter | ||
Comment 16•13 years ago
|
||
Comment on attachment 624877 [details] [diff] [review] Aurora uplift. [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky): String or UUID changes made by this patch: part of the meta/global implementation bundle of release blockers
Attachment #624877 -
Flags: approval-mozilla-beta?
Reporter | ||
Updated•13 years ago
|
Whiteboard: [qa+][want uplift during betaN, but not right now] → [qa+]
Updated•13 years ago
|
status-firefox14:
--- → affected
Updated•13 years ago
|
Attachment #624877 -
Flags: approval-mozilla-beta?
Attachment #624877 -
Flags: approval-mozilla-aurora?
Attachment #624877 -
Flags: approval-mozilla-aurora+
Comment 18•13 years ago
|
||
verified by - delete crypto keys using Components.utils.import("resource://services-sync/main.js"); Components.utils.import("resource://services-sync/resource.js"); function deletePath(path) { let resource = new Resource(Weave.Service.storageURL + path); resource.setHeader("X-Confirm-Delete", "1"); return resource.delete(); } deletePath("crypto/keys"); Sync desktop, then sync device. should get: 05-21 12:17:09.256: W/ServerSyncStage(2518): Remote engine syncID different from local engine syncID: resetting local engine and assuming remote engine syncID. bug 756549 sometimes is getting in the way.
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
Product: Mozilla Services → Android Background Services
Updated•7 years ago
|
Product: Android Background Services → Firefox for Android
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•