Skip to content
This repository has been archived by the owner on Apr 12, 2022. It is now read-only.

Upgrading from 0.6.8 to 0.6.9 forgets device verification state. #1039

Open
ara4n opened this issue Mar 18, 2017 · 4 comments
Open

Upgrading from 0.6.8 to 0.6.9 forgets device verification state. #1039

ara4n opened this issue Mar 18, 2017 · 4 comments
Labels

Comments

@ara4n
Copy link
Member

ara4n commented Mar 18, 2017

Reports from israuor in #riot:matrix.org that upgrading to 0.6.9 made his client forget which devices he'd verified, causing all messages to appear to be /! rather than green-padlock

@richvdh
Copy link
Member

richvdh commented Mar 18, 2017

I believe this was expected, according to @ylecollen: https://matrix.to/#/!GnEEPYXUhoaHbkFBNX:matrix.org/$14896768012RLdXK:h3ndr1k.de

I am unclear as to why this was necessary, though. It's certainly undesirable.

@ara4n
Copy link
Member Author

ara4n commented Mar 18, 2017

It's really undesirable. I know of some people who are patiently going through the process of verifying hundreds of devices (actually publishing physical printed lists of trusted base64 ID keys which then get manually cross-checked), and to suddenly delete all of the trust data during an upgrade without warning is not cool.

@ylecollen
Copy link
Contributor

The backward compatibility was broken with the unknown devices management (and other crypto updates).
It won't happen anymore because i fixed this serialisation managemen issuet.

I did not think it was a big issue because we have the unknown devices dialog which warns about them.

But, it is also not cool
1 - to do it on each client : the users have to verify the hundreds of devices on each clien he/she uses. The e2e keys export could contain the verified devices.
It would also be a backup on any client (web, android or IOS).
2 - that the server does not remove the devices after a sign out. Many devices might be obsolete.
For example, my accunt would have several hundreds of obsole devices if i don't delete them after a signout
3 - to not able to block the devices of an user even the new ones. It would save time.

@ara4n
Copy link
Member Author

ara4n commented Mar 19, 2017

The reason it is a big issue is that we encouraged the user to do a bunch of work (verifying devices), and then arbitrary deleted all that work from under them when they upgraded. Yes, the UnknownDeviceDialog helps by telling them that their work has been deleted... but we really shouldn't have deleted it in the first place.

Separately, in terms of the other issues:

  1. yes, not syncing verification data between clients sucks: Share device verification/blocking status between our own devices element-web#2537 is where we're tracking it on riot-web.
  2. yes, not deleting devices when you logout sucks: https://github.com/vector-im/riot-web/issues/3238 is the bug.
  3. yes, not cross-signing devices sucks: We could cross-sign devices to aid trust when new ones join a room element-web#2714 is the bug.

There are another 68 E2E issues over at https://github.com/vector-im/riot-web/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3Atype%3Ae2e which also suck, and we're trying to fix as fast as we can. (@richvdh should be back in e2e land this coming week).

In terms of confusion over this release in general: my concerns are:
a. that this upgrade bug snuck through
b. that we didn't hold off until MSISDN support was released in Synapse (I knew that it was due for this riot-android release, but just assumed that we wouldn't push it to users without sync on synapse)
c. that we should perhaps have planned some formal beta testing of this release (given how long it's been since the last one, and given the magnitude of the MSISDN changes)

However, this is mainly my fault for not tracking the release process properly or syncing with @lampholder before he pressed the button. I suggest we sit down tomorrow in person and work out how we can (ab)use Tom to coordinate between the mobile & web & backend teams for releases in general - after all, this is the core of his gig as delivery manager! :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants