~/.config/Signal/sql/db.sqlite now unencrypted?

[aurelg]

• I have searched open and closed issues for duplicates

Bug Description

Archlinux, up-to-date as of 2021-03-13: signal-desktop 1.40.1 suddenly refused to start with an error message SQLITE_NOTADB, very much like #4513. It then asked to re-link to Signal running on my phone. The database is recreated anew: all messages are gone. I can live with it.

However, after investigation, it seems that the database in ~/.config/Signal/sql/db.sqlite - that used to be encrypted with sqlcipher -, is now recreated without encryption: I can open it e.g. with sqlitebrowser without even entering the key that was stored in ~/.config/Signal/config.json.

I understand the encryption was pretty much useless since the key was stored in clear text, yet it surprises me that such a breaking change is implemented without further notification.

Steps to Reproduce

1. Start 1.40.1 till it complains with the SQLITE_NOTADB message
2. Relink your account, ~/.config/Signal/sql/db.sqlite is recreated

Actual Result:

After step 2,~/.config/Signal/sql/db.sqlite is not encrypted.

Expected Result:

After step 2, ~/.config/Signal/sql/db.sqlite should be encrypted.

Platform Info

Signal Version:

1.40.1

Operating System:

Archlinux up to date as of 2021-03-13.

Linked Device Version:

5.4.12

[primeos]

I can confirm that db.sqlite is also unencrypted on my system (Signal-Desktop 1.40.1 on Linux/NixOS) and I didn't even re-link recently (I last re-linked approx. 3 months ago). No complaints (I always wondered why the DB has to be encrypted if the key is stored using the same permissions) but given that .config/Signal/config.json still contains the key, that this was't mentioned in any changelog, and that a quick GitHub search doesn't reveal such a change or a reason for it this does certainly seem strange...

[eNTi]

Same here... I wasn't aware of the db being encrypted but that makes quite a lot of sense really.

Also losing all conversations and contacts is a quite annoying litte side effect.

[grantler]

I came to report the unexpected loss of the database. "Quite annoying" does not express how much of a major hassle this is. A recovery seems not to be possible. Maybe it can be left to the user if they want to set their take on the tradeoff between security and usability, e.g. mirror old messages between the phone and the desktop client.

[gkft]

@aurelg did you test whats happening if you purge the signal database install a not affected gtk3 version as described in #4513 (comment)?
If the database is encrypted afterwards then Signal correctly uses the bundled sqlcipher otherwise Signal somehow may use the system installation of sqlite.

[aurelg]

I did not (yet). I'm using signal-desktop "in production", and it makes experimenting not that trivial. I'll do it asap - except if someone else tries first! 👍

[gkft]

@LukeLR confirmed the behavior #4513 (comment)

Does it make sense to close this issue as the observed behavior is a consequence of #4513?

[aurelg]

Yes, I think it makes sense to close it. I'll follow #4513 very carefully. Thanks for your help! 👍

[primeos]

I've reopened this as #5245 because IMO this is Signal-Desktop's responsibility and their "unfortunate" design shouldn't waste the time of users and package maintainers.