Sometimes Riot will say a backup was created by an unknown device when it looks like the device should be known.

[lampholder]

https://github.com/matrix-org/riot-web-rageshakes/issues/1174

[lampholder]

I'll try and get some solid repro steps for this, if I can't we can still look at the code/add some logging to see what's going on.

[lampholder]

Well, I'm seeing it again. And the (extra) problem with it is that when key backup is in this state, you also get the wrong SMR warning when you go to an encrypted room, which invites you to click 'set up' and create a totally new backup

[lampholder]

Right, this time I:

• set up backup on device with ID UNMBGNLXWU
• looked at key backup settings on a different device
• the settings told me 'Backup has a signature from unknown device with ID UNWBGNLXWU'
• console logs told me 'Ignoring signature from unknown key ed25519:UNWBGNLXWU'

[lampholder]

@ara4n has offered to take a look at this.

[lampholder]

Thoughts from @dbkr:

so I would stick a breakpoint in KeyBackupPanel https://github.com/matrix-org/matrix-react-sdk/blob/master/src/components/views/settings/KeyBackupPanel.js#L64
the first theory I'd test is whether the devices in your device list have got our of sync with your list of keys
because, as I have just been reminded of, they are two different things
that list of devices above is the result of a /devices API call
but all the key backup stuff is based off the keys for devices which is a) from a different API endpoint entirely: /keys/query and b) stored in the client and hopefully updated when it changes
so what I suspect you'll see is that /devices think that device exists but it's not in our local 'cache' in the DeviceList class Encrypted by an unverified device

[lampholder]

console logs told me 'Ignoring signature from unknown key ed25519:UNWBGNLXWU'

This is a red herring - you get this whenever your backup has been signed by a device you haven't verified.

[lampholder]

Okay, I now know some things. The appearance of this issue is dependent upon the information stored in your indexeddb device_data table.

When you log in from a fresh client, this table contains a json object with a reference to just your new device. Certain things will trigger its being poplated with a full list of your devices:

• look at the memberinfo for your own account
• try and send a message in an encrypted room (you'll get the 'unknown devices present' notif, it doesn't matter how you respond to this)

Empirically, just logging in on a new device does not prompt your other devices to refresh their list of your devices stored in device_data.

The problem is, the key backup UX appears to be assuming that device_data has fresh device information, but it doesn't.

[lampholder]

Dave is 95% confident that adding a new device is supposed to trigger a poke to your existing devices prompting them to update their local device_data with your new device information.

As I said above, this isn't happening. If it were happening in the past, it could have been broken for ages without our noticing - prior to key backup, you only needed a fresh list of your devices before sending an encrypted message, and however it's happening device_data is being refreshed before that.

The upshot of this is if you create two devices, set up key backup on one and then try to use that backup on the second, your second device will say the backup is signed by an 'unknown' device.

You can force device_data to be refreshed by:

• trying to send a message in an encrypted room, or
• looking at your own memberinfo

The table of devices is populated by a call to /devices, so it contains fresh information.

[dbkr]

This ^ was almost certainly the cause of this bug