element-hq
After update: Your key storage is out of sync.
Steps to reproduce
All was fine and I got a notification to update the Element software and immediately on restart I get: Your key storage is out of sync.
Steps to repro: Have the old version with 5 client sessions and update.
The version that shows this: Element version: 1.12.5 Crypto version: Rust SDK 0.14.0 (c3b7918), Vodozemac 0.9.0
Outcome
Updates in the past never did this. I expect all to just work when updating.
Operating system
MacOS
Application version
No response
How did you install the app?
No response
Homeserver
No response
Will you send logs?
Yes
Not sure how this relates to: https://github.com/element-hq/element-web/pull/31279
This issue pertains to the MacOS desktop version. For now just ignoring that popup and all works fine. Why did this happen with the new update?
I got the same message on both of my Macs today after installing the latest update. I had to enter my recovery key on both (well, I'm not sure whether I had to, as things seemed to still work without it, but I did it anyway).
Not sure about my recovery key and where I have it. I think I only exported keys from my Windows PC
+1, Mac desktop, the same update version. The only notable thing in the changelog is the PR linked above as the potential culprit. Honestly, I'm not even sure this particular device had any key backup set up deliberately anyway, maybe something was done silently on login and sync from other devices. I've given up trying to understand how it all actually works.
None of my previously saved keys (NB: "security keys", as the dialog hints at these would work too) are accepted, so I went to the forgotten CTA and generated a new one; no idea what consequences that has as there's no information in the UI as to what are the options, what to do, and why. (My ideal option would be to just ignore this dialog, as I have no use for it and am probably not interested in the issue.)
Ideally though, given I have many devices and can verify or confirm cross signing as much as I want, I'd like to flush any local recovery key cache or backup decryption keys, and force fresh syncing… not sure what are my options besides completely resetting the client.
From the linked PR:
"This PR addresses the cases where key backup needs resetting, which happens when the user has key backup, but does not have access to the backup decryption key. That is, if the decryption key is missing both from the local cache and from 4S, or if the decryption key is missing from the local cache and the user has forgotten their recovery key."
Trying to wrap my head around this but not with much success how that applies to my case — perhaps the whole popup trigger is just a regression artifact from the PR above, a red herring in itself without any underlying issue?
The only thing that might be linked to this is, in encryption settings, I noticed the encrypted search cache shows an error Error opening the database: IndexError(IOError(IOError { path: None, err: Custom { kind: Other, error: "Invalid MAC" } })) so I just reset that to reindex.
Now the PC desktop version starts to do the same. Must have been a silent update.. I was not wanting the update but must have been automatic. Why is this new version doing this when all is fine!!! I never had a recovery key so why now this process? Why such little info on why this is now occurring?
This issue pertains to the MacOS desktop version. For now just ignoring that popup and all works fine. Why did this happen with the new update?
It is not (just) macOS desktop - I have the same issue on macOS desktop, but tried the web client https://app.element.io/ to see where best to report the issue, and exactly the same happens there.
Also, I tried authenticating my login using my recovery key, rather than another device, to confirm I have the recovery key right; and I do, it works fine for that.
Will you send logs?
Yes
Not seeing any logs from the OP or anyone else who has commented here. Please send debug logs from within the application, referencing this issue, so that we can investigate.
@uhoreg says: https://github.com/element-hq/element-web/pull/31279 changed things so that we now check if the local device is missing the key backup decryption key, so this seems like expected behaviour. It would still be good to double-check that is what @HarHarLinks is seeing, based on the logs.
@uhoreg says: #31279 changed things so that we now check if the local device is missing the key backup decryption key, so this seems like expected behaviour. It would still be good to double-check that is what @HarHarLinks is seeing, based on the logs.
What if I don't want a recovery key? I used to use the mode whereby there was no backup, but any one device could be used to authorize and provide historical messages to any other. That was disabled, but I still don't want a remote backup. Yet this is giving me no choice but to go through a process to recreate a key I don't want (or look at an undismissable dialog).
I do want key backup on my device.
I would expect that verifying using another device that has it (SchildiNext, Nheko) during login communicates the key properly to my Element Web session.
I would further expect that choosing the "Enter recovery key" option in the toast means that my client now has my keys. Instead after entering (and accepting? it's not explicit about that) my recovery key, it asks me to "Change recovery key", which is the other option from the toast I specifically decided against.
The biggest trouble I have with all this is complete intransparency about what specifically is supposedly going wrong, even when I'm in "Developer mode", and what the consequences of "Change recovery key" would be. Historically, touching anything like that would mean nuking my crypto identity which I want to absolutely avoid at all cost and which makes this 200% more scary to deal with.
@uhoreg says: #31279 changed things so that we now check if the local device is missing the key backup decryption key, so this seems like expected behaviour. It would still be good to double-check that is what @HarHarLinks is seeing, based on the logs.
What if I don't want a recovery key? I used to use the mode whereby there was no backup, but any one device could be used to authorize and provide historical messages to any other. That was disabled, but I still don't want a remote backup. Yet this is giving me no choice but to go through a process to recreate a key I don't want (or look at an undismissable dialog).
It should be checking whether backup was purposely disabled, and not display the warning in that case. I'll double-check whether that is the case, and if not, it should get fixed.
I do want key backup on my device.
I would expect that verifying using another device that has it (SchildiNext, Nheko) during login communicates the key properly to my Element Web session.
Yes, that's what should happen, but for whatever reason, we've found that sometimes devices don't have the backup key.
I would further expect that choosing the "Enter recovery key" option in the toast means that my client now has my keys. Instead after entering (and accepting? it's not explicit about that) my recovery key, it asks me to "Change recovery key", which is the other option from the toast I specifically decided against.
That is unexpected. I'll have to see what's going on in the logs.
The biggest trouble I have with all this is complete intransparency about what specifically is supposedly going wrong, even when I'm in "Developer mode", and what the consequences of "Change recovery key" would be. Historically, touching anything like that would mean nuking my crypto identity which I want to absolutely avoid at all cost and which makes this 200% more scary to deal with.
Yeah, it's a difficult balance between wanting to give the user enough information so that they know what's going on, but not too much so that error messages are too long and confusing to the "average" user. Unfortunately, "Your key storage is out of sync" is a situation that encompasses several different (but related) problems, having something to do with keys missing from local cache and/or from secret storage. "Developer mode" mostly just means that you get access to the developer tools dialog. Not much else changes in the UI. But if you have access to the developer tools, you can click on the "End-to-end encryption" button and try to see what is wrong. If all the secrets are present, you should see something like the following (the underlined lines are the important bits):
Worth noting that https://github.com/element-hq/element-web/issues/30438 tracks some improvements to the toast to at least let the user know if the secret is missing from the local device, or the server-side store.
@uhoreg says: #31279 changed things so that we now check if the local device is missing the key backup decryption key, so this seems like expected behaviour. It would still be good to double-check that is what @HarHarLinks is seeing, based on the logs.
What if I don't want a recovery key? I used to use the mode whereby there was no backup, but any one device could be used to authorize and provide historical messages to any other. That was disabled, but I still don't want a remote backup. Yet this is giving me no choice but to go through a process to recreate a key I don't want (or look at an undismissable dialog).
It should be checking whether backup was purposely disabled, and not display the warning in that case. I'll double-check whether that is the case, and if not, it should get fixed.
Indeed, it looks like this case was missed, and I've created https://github.com/element-hq/element-web/issues/31494 to track this issue. A fix is incoming, but needs to wait for another PR to be merged first, due to conflicts.
@uhoreg are we happy to assume everyone is experiencing #31494, and if so can we remove the X-Needs-Info label and close this as a duplicate?
I don't think that everyone is experiencing #31494. I think that for some people, it is due to the new check correctly noticing that the backup key is missing. However, that is correct behaviour, and not a bug. But I still want to look at HarHarLinks' rageshake to confirm that is what they're seeing (and if anyone else wants to submit rageshakes, I'll look at them too). So we should wait a bit before closing.
But given that we have a rageshake, we can remove the X-Needs-Info label.
if anyone else wants to submit rageshakes, I'll look at them too
Sent - from Windows app, with the undismissable dialog showing. Can also send from macOS app later.
Looking at the logs from HarHarLinks and mikebeaton, they are both indicating that Element is missing the backup key locally. However, the backup key is present in Secret Storage for both, so if you can enter your recovery keys, then it should be fixed.
Looking at the logs from HarHarLinks and mikebeaton, they are both indicating that Element is missing the backup key locally. However, the backup key is present in Secret Storage for both, so if you can enter your recovery keys, then it should be fixed.
I can't enter my recovery key - it accepts it and then immediately puts me into the process of creating a new one. Or, if that's the intended process, then I don't understand why after this update I am being sent down that process at all, since everything was fine before!
it accepts it and then immediately puts me into the process of creating a new one. Or, if that's the intended process, then I don't understand why after this update I am being sent down that process at all, since everything was fine before!
same here and, per my previous comment, agree. nor does this explain why the key was not transferred automatically from my other device during verification.
Right, it should not ask you to create a new recovery key. I'll take a look into that.
As for why the key was not transferred from your other device during verification, it could be that the other client does not have the key either. IIRC at one point, Element did not cache the backup key, and it was only used when you manually told it to fetch keys from the backup. Other clients could also not be caching the backup key.
Nheko specifically tells me it has Online backup key as well as SSK, USK, MSK all cached. I don't know how to look up the same on SchildiNext/Element X.
Here is a screenshot from the affected Element Web session:
Right, it should not ask you to create a new recovery key. I'll take a look into that.
I was unable to reproduce that situation. It will ask you to change your recovery key if accessing the secret storage fails for whatever reason, but we seem to be short on logging in that area, so I can't tell what's failing. I'll have to add more logging, and then ask you both to re-submit logs.
app.element.io was updated. the toast has disappeared for me, despite the info in devtools being unchanged which i read as something is broken.