Open posita opened 2 days ago
Sorry about your corrupted database! That's not great, but it's fortunate you had a backup. It's not clear based on the logs what happened, and I just ran a test on Linux to migrate from 7.32 to 7.33 and wasn't able to reproduce the problem. Also it's interesting that 7.31 to 7.33 was working. Has anything changed with your system password store recently?
Has anything changed with your system password store recently?
Not that I know of, but how would I know for sure? My ~/.config/Signal/config.json
both pre- and post-upgrade indicates:
{
// ...
"safeStorageBackend": "gnome_libsecret"
}
Does that help?
Hm that is as expected. Thank you for checking it.
I'm experiencing the same error on macOS, not after updating Signal but after migrating to a new Mac using Migration Assistant:
Database startup error:
Error: Error while decrypting the ciphertext provided to safeStorage.decryptString.
at getSQLKey ([REDACTED]/app/main.js:1280:39)
at initializeSQL ([REDACTED]/app/main.js:1329:11)
at App.<anonymous> ([REDACTED]/app/main.js:1551:20)
App Version: 7.34.0
OS: darwin
The version on the new machine was 7.33.0 originally; manually replacing the app with 7.34.0 didn't change anything.
The new machine is running Sequoia 15.1. The same database on the original machine (which is running Ventura 13.7) continues to work fine.
Deleting ~/Application Support/Signal and replacing it with the folder from the original machine or from a backup yields the same error on the new machine. Only deleting and starting from scratch works normally.
I made certain the migrated/copied folder was bit-identical on the new machine, so I'm not sure this is actual database corruption. FWIW, I can copy the "corrupted" folder back to the old machine and it works fine again there.
Assistance would be greatly appreciated. Please let me know if/how I can provide further details.
I was able to solve my problem. Since true database corruption seemed unlikely and missing/changing keys were mentioned in other places by other users, I looked into macOS's keychain and found a different "Signal Safe Storage" key than on the original machine. Once I overwrote the new key with the old one, Signal upon launch only asked permission to use this changed keychain item, and when granted opened the existing database fine, with all messages preserved.
I don't know what caused a wrong key to be stored – unfortunately I can't tell now whether Migration Assistant migrated the existing key properly in the first place, and thus, whether this was a Signal or a Migration Assistant issue.
Edit: Also, it is now obvious that mine was a different issue from the OP's, so apologies for hijacking this thread.
I should have been clearer about my "restor[ing] ... from a backup". I copied my ~/.config/Signal
directory from another instance. More specifically, I run two copies of Signal on my desktop. One from the deb
repo (whose config lives at ~/.config/Signal
) and one from the Flatpak repo (whose config lives at ~/.var/app/org.signal.Signal/config/Signal
). I started doing this when the Flatpak version ended up corrupting databases a few weeks ago and I basically lost some message history, which was very painful for me. (Copying message history is a high-demand-but-ignored feature request.) When my apt/deb version suddenly resulted in a database error, I quit that one and the Flatpak one. Then I unlinked both from my mobile app, deleted ~/.config/Signal
, copied ~/.var/app/org.signal.Signal/config/Signal
into its place, and restarted/re-linked both desktop clients.
I have the same problem on MacOS but with an update from Sequoia 15.1 to 15.1.1 or Signal Desktop from 7.32 to 7.33 (Signal updated right after the reboot for the MacOS update, so I am not sure what triggered it. Reverting back to 7.32 from a backup sadly did not change it.
Using a supported version?
Overall summary
I keep my Ubuntu system up-to-date (by the week). I am keeping Signal up-to-date with the official repository. Immediately after upgrading to 7.33 from the immediately prior version, I was presented with:
Downgrading to 7.32 and then 7.31 did not help. (The database remained corrupted.) This sounds similar to #7089, but I keep my system up-to-date. Possibly related to #7029,
#7054[EDIT: no, that's a different issue], but those involve different versions.From the command line:
Steps to reproduce
Expected result
Not to have my database be permanently corrupted after an upgrade.
Actual result
Database was corrupted after upgrade to 7.33 and downgrading to 7.32 and 7.31 (e.g.,
sudo apt-get purge --auto-remove signal-desktop && sudo apt-get install signal-deskop=7.31.0
) did not help. I was able to restore~/.config/Signal
from a backup, unlink, and then relink the desktop client, which allowed me to proceed. Upgrading back to 7.33 from 7.31 did not exhibit the same crash (i.e., it continued to work with the backed up database). If I didn't not have the backup, I would have lost all message history on desktop. The corresponding feature request appears largely ignored for the past six years.Screenshots
No response
Signal version
7.33
Operating system
Ubuntu (Pop!_OS) 22.04
Version of Signal on your phone
7.36 (429)
Link to debug log
No response