New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signal Desktop faulty version potentially causing data loss #108772
Comments
Sorry to hear that. I recently lost my history too... It's really frustrating!
Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers).
Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. |
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing:
This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though 🙃 Opened a PR: #117555 |
FYI, in case anyone has feedback/suggestions: We might merge #117555 soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable). |
Well, this should test if the database is encrypted but currently it is still unencrypted and we need to notice if this behaviour changes in the future (as it will cause data loss, see e.g. NixOS#108772). Anyway, this doesn't really matter for security reasons but we need this test to prevent data loss (unfortunately Signal-Desktop and SQLCipher handle this badly... :o).
AFAIK this is the only reliable way for us to ensure SQLCipher will be loaded instead of SQLite. It feels like a hack/workaround but according to the SQLCipher developers [0] "this issue can and should be handled downstream at the application level: 1. While it may feel like a workaround, using LD_PRELOAD is a legitimate approach here because it will substitute the system SQLite with SQLCipher which is the intended usage model;". This fixes NixOS#108772 for NixOS 20.09 users who upgrade to NixOS 21.05 and replaces NixOS#117555. For nixos-unstable users this will unfortunately break everything again so we should add a script to ease the transition (in a separate commit so that we can revert it for NixOS 21.05). [0]: sqlcipher/sqlcipher#385 (comment)
Well, this should test if the database is encrypted but currently it is still unencrypted and we need to notice if this behaviour changes in the future (as it will cause data loss, see e.g. NixOS#108772). Anyway, this doesn't really matter for security reasons but we need this test to prevent data loss (unfortunately Signal-Desktop and SQLCipher handle this badly... :o). (cherry picked from commit 217f268)
Heads-up: I've just merged #122926 to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup |
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended |
Describe the bug
Just lost on two different NixOS machine my Signal Desktop history because of this faulty update...
I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss
signalapp/Signal-Desktop#4513
To Reproduce
Steps to reproduce the behavior:
Notify maintainers
@primeos (@ixmatus and @equirosa)
The text was updated successfully, but these errors were encountered: