Open lampholder opened 4 months ago
Yeeees.
The first prompt ("Use your security key to continue", with the stupid "upload" button) is the AccessSecretStorageDialog
. This is shown because RestoreKeyBackupDialog
(correctly) determines that the backup key is in 4S, and therefore calls SecurityManager.accessSecretStorage
to get hold of the 4S key. This completes successfully, restores the backup, and enables upload of new keys to backup. However, it doesn't correctly feed this information back to RestoreKeyBackupDialog.recoverInfo
.
The second prompt ("Enter security key") is fallback code meant to handle the case when the backup key is not stored in secret storage, and instead is prompting you to enter your backup key directly. Since you don't know the backup key (it is not the same as the 4S key), it's impossible to enter this key and you are shown an error. (Presumably if you did somehow know the backup key, we would attempt to restore it again.)
This is not a new issue; it also happens with legacy crypto.
Ideally I think this whole fallback flow would be removed, but that's not actually the problem here: all we need is to make sure that recoverInfo
is correctly populated when the recovery completes. And, for the love of God, some tests for this flow.
This is a duplicate of https://github.com/element-hq/element-web/issues/26247, but this is a better description of the issue, so closing that one.
Steps to reproduce
Outcome
What did you expect?
Operating system
mac
Browser information
Firefox
URL for webapp
app and develop
Application version
Element version: 482b81b0ed5f-react-6e31f691189e-js-d421e7f82904 Crypto version: Rust SDK 0.7.0 (61b175b), Vodozemac 0.5.1 and whatever the latest release is
Homeserver
lant.uk
Will you send logs?
No