Closed Bug 618935 Opened 14 years ago Closed 12 years ago

passphrases will not migrate to sync keys in all cases

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mconnor, Unassigned)

References

Details

(Whiteboard: relnote)

The syncID (stored in meta/global) is used as the salt when deriving the Sync Key from an old-style passphrase.  In certain cases affecting nightly users, migration may not happen cleanly.  This is tied to the storage format, in that if you move from v3 to v4 to v5, this is probably transparent.  If you then try to migrate another client directly from v3 to v5, you will generally get a "wrong sync key" error on login.

The workaround is to either manually enter the new Sync Key, or choose "stop using this account" on the affected client, then set up the device again using the new easy setup process.
(In reply to comment #0)
> The syncID (stored in meta/global) is used as the salt when deriving the Sync
> Key from an old-style passphrase.  In certain cases affecting nightly users,
> migration may not happen cleanly.  This is tied to the storage format, in that
> if you move from v3 to v4 to v5, this is probably transparent.  If you then try
> to migrate another client directly from v3 to v5, you will generally get a
> "wrong sync key" error on login.

If you migrate all of your client from v3 to v5 (which is what the vast majority of our users are going to be doing), do you still get the "wrong sync key" error on login? My understanding is that it's *not* the case and that the transition will happen transparently, but would like you to confirm.
No.  This only affects users who went through 3 -> 4 -> 5
When was v3 issued? I'm having trouble mapping those version numbers to product releases.
(In reply to comment #3)
> When was v3 issued? I'm having trouble mapping those version numbers to product
> releases.

v3 is what is currently out on the "production" channels: Fx b7, Fennec b2, add-on 1.5.x, Fx Home 1.0.4.
v3 is the storage version used in Sync 1.5 (addon).

v4 was introduced in simple crypto, December 1st nightlies on.

v5 was introduced on December 9th to fix an argument order discrepancy in our key derivation function (for both crypto and J-PAKE). It's identical to v4 but for the fact that we generate different keys from the same input. We bumped the storage version to cause old clients to prompt for an upgrade rather than just failing.

There are a small set of v4 builds -- 8 or 9 nightlies, and 1.6b1 and 1.6b2 Sync addons. It's not a supported storage version going forward.
Is this data saved anywhere (sync server side?) so we could see how many people could possibly be affected?

Is there a way by looking at user systems to know that they went 3->4->5-> rather than 3->5 so that we can have an easy way to identify / discount those bug reports?
can we relnote this if we're note fixing it for beta8?  most people out in the world are going to be going from v3->v5.

Tony
Whiteboard: relnote
(In reply to comment #7)
> can we relnote this if we're note fixing it for beta8?  most people out in the
> world are going to be going from v3->v5.

That appears to be the plan of record:

https://bugzilla.mozilla.org/show_bug.cgi?id=618335#c3
I'm currently getting "unknown error" trying to sync on both of my desktop machines. I suspect they both went through v3->v4->v5 since I was actively using them and updating them around that timeframe. I've also been actively using and updating my Mac laptop, and I setup sync on Firefox Mobile just recently. I can't seem to get my desktop machines to work by doing "stop using this account" on one of them and re-setting it up using "add a device" from the other.

Any ideas on how I can get this working again? Any info I could provide that would be useful?
We're not worried about this now. Its time has passed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.