Open richvdh opened 10 months ago
Interesting that you close a ticket which was opened earlier than this one...
Interesting that you close a ticket which was opened earlier than this one...
This one doesn't even contain the "steps to reproduce" etc. from #23497.
I'm copying the info from #23497 so that it doesn't get lost:
A message like "This session is backing up your keys"
"This session is not backing up your keys"
Ubuntu 22.04.1
1.11.10
flatpak install flathub im.riot.Riot
Synapse 1.68.0
Yes
I think this issue should be tagged with S-Major
like #23497 since it will lead to major data loss for many people.
Some additional context on that.
There used to be the notion of local trust for backup. So when the backup was not trusted, the UX was showing a Connect Backup
button. This flow was asking the user for the passphrase, and if succesfull the backup was marked as locally trusted, meaning that it was then correctly backing up keys (upload).
For security concerns, the local trust was removed. Now the only way a backup is trusted is if it has a valid signature from the user cross-signing keys.
So it's not technically possible at the moment to connect a backup
.
We need to review the backup design, and properly handle backup with invalid signatures. We also need to properly define how to update backup signatures in case of cross-signing keys change
@BillCarsonFr How can I sign a backup with my cross-signing keys, such that my session is properly and automatically backed up?
@BillCarsonFr How can I sign a backup with my cross-signing keys, such that my session is properly and automatically backed up?
I can just give a work around for now.
You have already imported the keys from backup, but out of security you should manually export them to a file (Security & Privacy > Export E2E room keys
.
Then in the backup section, you can use the reset button (on the right of the Connect Backup
).
This will create a new empty backup that will be signed correctly. All the keys knowm locally will then get uploaded to that new backup (it will take some time). And any new key will get uploaded also as the backup will be trusted now
Actually as pointed by @poljar, as per spec, there are 2 ways to trust a backup. The second way is:
by deriving the public key from a private key that it obtained from a trusted source. Trusted sources for the private key include the user entering the key, retrieving the key stored in secret storage, or obtaining the key via secret sharing from a verified device belonging to the same user.
So in that case, it would make sense to add the cross-signing signature if it was missing. Or at least consider the backup as locally trusted? and upload to it
For example, if your backup is not signed with a trusted key, then "connect to backup" will report:
... but we (correctly) do not actually start uploading keys to the backup.
The logs report:
Or, on legacy crypto: