Skip to content
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

Closed
norpol opened this issue Jan 8, 2021 · 5 comments · Fixed by #122926
Closed

Signal Desktop faulty version potentially causing data loss #108772

norpol opened this issue Jan 8, 2021 · 5 comments · Fixed by #122926

Comments

@norpol
Copy link
Contributor

norpol commented Jan 8, 2021

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:

  1. Upgrade Signal Desktop
  2. Restart Signal Desktop
  3. Asks you to delete db, if you interact in a wrong way it will delete your data

Notify maintainers

@primeos (@ixmatus and @equirosa)

@primeos
Copy link
Member

primeos commented Jan 8, 2021

Just lost on two different NixOS machine my Signal Desktop history because of this faulty update...

Sorry to hear that. I recently lost my history too... It's really frustrating!

I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss

Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers).
AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in pkgs/applications/networking/instant-messengers/signal-desktop/default.nix).

I hate Signals way of dealing with long term conversations and history archival, it sucks - there are no proper ways of dealing with this. @moxie0

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 raged a bit here https://social.primeos.dev/notice/A22N5eEVCDrkxyDmwy but after I realized that one cannot even import old backups I had to take a break.)

@RaitoBezarius
Copy link
Member

RaitoBezarius commented Mar 25, 2021

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:

pkgs.signal-desktop.override {
  gtk3 = pkgs.gtk3.override { trackerSupport = false; };
}

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

@primeos
Copy link
Member

primeos commented Apr 14, 2021

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).

primeos added a commit to primeos/nixpkgs that referenced this issue May 13, 2021
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).
primeos added a commit to primeos/nixpkgs that referenced this issue May 14, 2021
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)
primeos added a commit to primeos/nixpkgs that referenced this issue May 15, 2021
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)
@primeos
Copy link
Member

primeos commented May 17, 2021

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 ~/.config/Signal/ first in case the script fails unexpectedly.

@norpol
Copy link
Contributor Author

norpol commented May 23, 2021

Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants