617047 - Upgrade step yields to different Sync Keys

Status: RESOLVED WORKSFORME

(Firefox :: Sync, defect)

Description

[Philipp von Weitershausen [:philikon]]

I bunch of people reported this on the mailing list and Shaver just ran into it now: Upgrading different machines to new crypto yields to different keys sometimes. We're not sure when exactly this happens, but a strong suspect is the master password. Shaver has it enabled.

My suspicion is that verifyLogin() will not check whether the master password is locked and just try to get the old passphrase from the password manager. That yields "null", "undefined", an exception, or whatever as the input to PBKDF2. What it should do is detect whether the MP is locked (Utils.mpLocked()) and just not log in. (Eventually we want to prompt for the master password at that stage, but that's for another bug... bug 543784 to be precise.)

Comment 1

[:Gavin Sharp [email: [e-mail]]]

This happened to me, and I don't have a master password enabled. I have three profiles with Sync.
  a) 3.6.12 with 1.6.b1 addon (Mac)
  b) trunk nightly (same Mac)
  c) 3.6.12 with 1.6b1 (Windows)

I updated a) and c) to 1.6b1 at different times (not sure of the order), and a) ended up with the wrong key. The other one and the trunk nightly were still working fine.

Comment 2

[Richard Newman [:rnewman]]

Well, this is a weird one.

As I mentioned on IRC, there are only three ways this could happen:

  1. PBKDF2 is unreliable in some way;
  2. the syncID retrieved by the two separate upgrade processes differed (e.g., silently empty meta/global);
  3. the passphrase retrieved on one was different (e.g., master password causing it to be a bad value)

None of these seem to be particularly good candidates for causing this...

Hmm. *dons thinking cap*

Comment 3

[Richard Newman [:rnewman]]

This isn't immediately reproducible for me.

Our current theory is that a server-side problem is causing stale collections data (old timestamps) to be returned from memcached. 

Consequently, the next client isn't aware of the first's completed upgrade, and strikes out on its own... only to be unable to decrypt at a later stage, reporting an incorrect sync key.

See Bug 617080.

I'm going to attempt to verify this locally.

Comment 4

[Richard Newman [:rnewman]]

Fingers crossed that a combination of Bug 615926 and Bug 617080 is the culprit for this, because the client code really shouldn't be causing this problem.

We've landed a fix (we think) for the former, and the server guys are fixing the latter. I'm going to mark this WORKSFORME. Reopen if it occurs again after those two bugs are closed...