Database Error

[rdong8]

Without fail, after having Signal installed for a few days, this error ends up appearing after trying to open it.

[sukahiroaki]

I'm getting this at the second start after the recent update for #729 . And by that I mean EVERY second time. New profile: Works first time, at second start I get this dialog. Delete all data > connect > works > at second start broken.

Hope this is some weird problem with my system bc if not the recent update just wrecked the local data of all Signal Flatpak users...

[sukahiroaki]

Another pointer: There were reports about keyring integration trashing the db weeks ago in another bug report #691 So I'm definitely not alone with this.

[Greenheart]

Same here. Spent 30 minutes trying to find a fix but it doesn't work yet. Lost a long history unfortunately.

• I tried downgrading to an older version using flatpak update --commit [hash] org.signal.Signal, but still got the database error on startup.
• I tried changing back to the most recent build (from earlier today) and deleting the database. Could start the app, but the next time I re-open it, the same error appears. Signal is currently unusable on desktop.

I wonder if the recent change regarding the system keyring requires user action to give more permissions (e.g. reading/writing the keyring)? Could it be possible to add these permissions via the flatpak CLI or via Flatseal?

[sukahiroaki]

Only way to fix it right now for me is by deleting all data, removing org.freedesktop.secrets via Flatseal and do a fresh setup.

[Greenheart]

Thank you! :pray: I can confirm that works as a workaround until the underlying issue is resolved. Definitely is related to org.freedesktop.secrets since removing that via Flatseal resolves the issue and enables use of Signal again. Unfortunately forcing to link the devices again, but that's better than a completely unusable version.

[bermeitinger-b]

This is typically not a flatpak issue but an issue of the password storage. Are you using kwallet, kwallet5, kwallet5, or gnome-keyring?

You could use --password-store=basic to restore the old behavior.

[Greenheart]

I'm using gnome-keyring version 46.2

[salim-b]

You could use --password-store=basic to restore the old behavior.

I can confirm that evades the problem.

Is there also an environment variable to configure this, so we could set this via flatpak override / Flatseal until the underlying (Electron?) bug is fixed?

This is typically not a flatpak issue but an issue of the password storage. Are you using kwallet, kwallet5, kwallet5, or gnome-keyring?

I'm also using gnome-keyring (on Bluefin):

❯ gnome-keyring version
gnome-keyring: 42.1

Using Key Rack I could see entries created for Signal. Of course, they aren't created anymore with --password-store=basic.

[bermeitinger-b]

This seems to be an error chain. Electron doesn't tell Signal the correct running instance (gnome-libsecret or kwallet) and Signal does not handle this well. It encrypts the database, then tries to write the encryption key but this fails (silently?), and upon the next start, it obviously can't get the encryption key.

[konomikitten]

Getting this issue as well now with the latest update. I expect as the latest update filters through there will be more people hitting this issue.

[Altonss]

I have the same issue, see here https://github.com/flathub/org.signal.Signal/pull/729#issuecomment-2373851290 :(

[konomikitten]

I did some digging in the electron project and apparently this bug is known but was just closed with no fix? See bug: https://github.com/electron/electron/issues/32598

[bermeitinger-b]

In your case, do you use Gnome, KDE or xfce? There, chromium should be able to detect the desktop environment correctly and use the corresponding password store.

However, e.g. for niche environments like i3, this detection will return "unknown" or fallback to "basic_string". If you want to use the gnome-keyring for generating and storing the encryption key, you must append the --password-store=gnome-libsecret to the command.

Without a proper log this can't be diagnosed why OPs message is shown.

What you also could do is change your XDG_CURRENT_DESKTOP variable. Chromium only "supports" the main ones: https://github.com/chromium/chromium/blob/f0ad7acd54334c73380f6d8e4e1b48915c973655/base/nix/xdg_util.cc#L102

Fortunately, chromium supports a list of current desktops and it will use the first one it supports. I've added this to my ~/.profile:

export XDG_CURRENT_DESKTOP="${XDG_CURRENT_DESKTOP}:XFCE"

This will tell chromium to fallback to XFCE, if the first one is not supported (in my case i3).

[mkhl]

I'm seeing this problem on GNOME though…

Without a proper log this can't be diagnosed why OPs message is shown.

What kind of log do you need? This is the output of flatpak run org.signal.Signal:

Debug: Will run signal with the following arguments:
Debug: Additionally, user gave: 
Set Windows Application User Model ID (AUMID) { AUMID: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR /app/Signal/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME bat
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/mkhl/.var/app/org.signal.Signal/config/Signal
config/get: Successfully read user config file
config/get: Successfully read ephemeral config file
making app single instance
LaunchProcess: failed to execvp:
xdg-settings
LaunchProcess: failed to execvp:
xdg-settings

(signal-desktop:2): Gtk-WARNING **: 15:57:28.246: Theme parsing error: gtk.css:3:63: 'color-mix' is not a valid color name
Gtk-Message: 15:57:28.319: Failed to load module "canberra-gtk-module"
Gtk-Message: 15:57:28.320: Failed to load module "canberra-gtk-module"
{"level":30,"time":"2024-09-26T13:57:28.834Z","msg":"got fast localeOverride setting null"}
{"level":30,"time":"2024-09-26T13:57:28.835Z","msg":"app.ready: hour cycle preference: UnknownPreference"}
{"level":30,"time":"2024-09-26T13:57:28.835Z","msg":"app.ready: preferred system locales: en-US, en"}
{"level":30,"time":"2024-09-26T13:57:28.835Z","msg":"locale: Supported locales: af-ZA, ar, az-AZ, bg-BG, bn-BD, bs-BA, ca, cs, da, de, el, en, es, et-EE, eu, fa-IR, fi, fr, ga-IE, gl-ES, gu-IN, he, hi-IN, hr-HR, hu, id, it, ja, ka-GE, kk-KZ, km-KH, kn-IN, ko, ky-KG, lt-LT, lv-LV, mk-MK, ml-IN, mr-IN, ms, my, nb, nl, pa-IN, pl, pt-BR, pt-PT, ro-RO, ru, sk-SK, sl-SI, sq-AL, sr, sv, sw, ta-IN, te-IN, th, tl-PH, tr, ug, uk-UA, ur, vi, yue, zh-CN, zh-HK, zh-Hant"}
{"level":30,"time":"2024-09-26T13:57:28.836Z","msg":"locale: Preferred locales: en-US, en"}
{"level":30,"time":"2024-09-26T13:57:28.836Z","msg":"locale: Locale Override: null"}
{"level":30,"time":"2024-09-26T13:57:28.838Z","msg":"locale: Matched locale: en"}
{"level":40,"time":"2024-09-26T13:57:28.873Z","msg":"intl.onWarn [@formatjs/intl] \"defaultRichTextElements\" was specified but \"message\" was not pre-compiled. \nPlease consider using \"@formatjs/cli\" to pre-compile your messages for performance.\nFor more details see https://formatjs.io/docs/getting-started/message-distribution"}
{"level":30,"time":"2024-09-26T13:57:28.874Z","msg":"locale: Text info direction for en: ltr"}
{"level":30,"time":"2024-09-26T13:57:28.874Z","msg":"getSQLKey: decrypting key"}
{"level":30,"time":"2024-09-26T13:57:28.875Z","msg":"getSystemTraySetting got value DoNotUseSystemTray"}
{"level":30,"time":"2024-09-26T13:57:28.875Z","msg":"getSystemTraySetting returning DoNotUseSystemTray"}
{"level":30,"time":"2024-09-26T13:57:28.876Z","msg":"app ready"}
{"level":30,"time":"2024-09-26T13:57:28.876Z","msg":"starting version 7.24.1"}
{"level":30,"time":"2024-09-26T13:57:28.876Z","msg":"media access status [object Undefined] [object Undefined]"}
{"level":30,"time":"2024-09-26T13:57:28.878Z","msg":"got fast theme-setting value system"}
{"level":30,"time":"2024-09-26T13:57:28.888Z","msg":"got fast theme-setting value system"}
{"level":30,"time":"2024-09-26T13:57:28.888Z","msg":"got fast spellcheck setting true"}
{"level":30,"time":"2024-09-26T13:57:28.889Z","msg":"Initializing BrowserWindow config: {\"show\":false,\"width\":1024,\"height\":667,\"minWidth\":300,\"minHeight\":200,\"autoHideMenuBar\":true,\"titleBarStyle\":\"default\",\"backgroundColor\":\"#3a76f0\",\"webPreferences\":{\"devTools\":false,\"spellcheck\":true,\"enableBlinkFeatures\":\"CSSPseudoDir,CSSLogical\",\"enablePreferredSizeMode\":true,\"nodeIntegration\":false,\"nodeIntegrationInWorker\":false,\"sandbox\":false,\"contextIsolation\":true,\"preload\":\"[REDACTED]/preload.bundle.js\",\"backgroundThrottling\":true,\"disableBlinkFeatures\":\"Accelerated2dCanvas,AcceleratedSmallCanvases\"},\"icon\":\"[REDACTED]/images/signal-logo-desktop-linux.png\",\"x\":0,\"y\":296}"}
{"level":30,"time":"2024-09-26T13:57:28.940Z","msg":"spellcheck: user locales: [\"en-US\",\"en\"]"}
{"level":30,"time":"2024-09-26T13:57:28.940Z","msg":"spellcheck: available spellchecker languages: [\"af\",\"bg\",\"ca\",\"cs\",\"cy\",\"da\",\"de\",\"de-DE\",\"el\",\"en\",\"en-AU\",\"en-CA\",\"en-GB\",\"en-GB-oxendict\",\"en-US\",\"es\",\"es-419\",\"es-AR\",\"es-ES\",\"es-MX\",\"es-US\",\"et\",\"fa\",\"fo\",\"fr\",\"fr-FR\",\"he\",\"hi\",\"hr\",\"hu\",\"hy\",\"id\",\"it\",\"it-IT\",\"ko\",\"lt\",\"lv\",\"nb\",\"nl\",\"pl\",\"pt\",\"pt-BR\",\"pt-PT\",\"ro\",\"ru\",\"sh\",\"sk\",\"sl\",\"sq\",\"sr\",\"sv\",\"ta\",\"tg\",\"tr\",\"uk\",\"vi\"]"}
{"level":30,"time":"2024-09-26T13:57:28.940Z","msg":"spellcheck: setting languages to: [\"en-US\",\"en\"]"}
2024-09-26 15:57:29.099: ERROR CORE sqlcipher_page_cipher: hmac check failed for pgno=1
2024-09-26 15:57:29.099: ERROR CORE sqlite3Codec: error decrypting page 1 data: 1
2024-09-26 15:57:29.099: ERROR CORE sqlcipher_codec_ctx_set_error 1
{"level":40,"time":"2024-09-26T13:57:29.099Z","msg":"MainSQL: Database log code=26: file is not a database in \"PRAGMA journal_mode = WAL\""}
{"level":30,"time":"2024-09-26T13:57:29.099Z","msg":"MainSQL: migrateDatabase: Migration without cipher change failed"}
2024-09-26 15:57:29.159: ERROR CORE sqlcipher_page_cipher: hmac check failed for pgno=1
2024-09-26 15:57:29.159: ERROR CORE sqlite3Codec: error decrypting page 1 data: 1
2024-09-26 15:57:29.159: ERROR CORE sqlcipher_codec_ctx_set_error 1
{"level":40,"time":"2024-09-26T13:57:29.159Z","msg":"MainSQL: Database log code=26: statement aborts at 2: [PRAGMA user_version] file is not a database"}
{"level":50,"time":"2024-09-26T13:57:29.160Z","msg":"MainSQL: Database startup error: SqliteError: file is not a database\n    at Database.pragma ([REDACTED]/node_modules/@signalapp/better-sqlite3/lib/methods/pragma.js:11:31)\n    at getUserVersion ([REDACTED]/ts/sql/util.js:132:13)\n    at migrateSchemaVersion ([REDACTED]/ts/sql/Server.js:404:54)\n    at openAndMigrateDatabase ([REDACTED]/ts/sql/Server.js:436:5)\n    at openAndSetUpSQLCipher ([REDACTED]/ts/sql/Server.js:458:14)\n    at initialize ([REDACTED]/ts/sql/Server.js:496:10)\n    at MessagePort.<anonymous> ([REDACTED]/ts/sql/mainWorker.js:69:41)\n    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:820:20)\n    at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28)"}
{"level":50,"time":"2024-09-26T13:57:29.160Z","msg":"Failed to get zoom factor {\"name\":\"SqliteError\"}"}
{"level":30,"time":"2024-09-26T13:57:29.615Z","msg":"got fast theme-setting value system"}
{"level":50,"time":"2024-09-26T13:57:30.344Z","msg":"sql.initialize was unsuccessful; returning early"}
{"level":30,"time":"2024-09-26T13:57:30.345Z","msg":"close event {\"readyForShutdown\":false,\"shouldQuit\":false}"}
{"level":30,"time":"2024-09-26T13:57:30.345Z","msg":"maybeRequestCloseConfirmation: Checking to see if close confirmation is needed"}
{"level":50,"time":"2024-09-26T13:57:33.781Z","msg":"onDatabaseError: Quitting application"}
{"level":30,"time":"2024-09-26T13:57:33.783Z","msg":"main window closed event"}
{"level":30,"time":"2024-09-26T13:57:33.783Z","msg":"quit event {\"hasEventBeenPrevented\":false,\"windowCount\":0,\"mainWindowExists\":false}"}
{"level":50,"time":"2024-09-26T13:57:33.784Z","msg":"Error occurred in handler for 'sql-channel:read': {\"name\":\"SqliteError\"}"}

[x80486]

I'm getting the same error...time and time again. Do you need to add shared-modules/libsecret/libsecret.json to the modules' list?

XDG_CURRENT_DESKTOP (for me) is set to GNOME.

[konomikitten]

I tried doing:

flatpak run org.signal.Signal --password-store=gnome-libsecret

The bug persisted so something else is a problem here.

Also:

[📦 org.signal.Signal ~]$ printenv XDG_CURRENT_DESKTOP
XFCE

$ gnome-keyring version
gnome-keyring: 46.2

[caseybecking]

Same issue here -

uname -a
Linux debian12 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux

printenv XDG_CURRENT_DESKTOP
i3:XFCE

gnome-keyring version
gnome-keyring: 42.1

[TiagoTiago]

Btw, if you got a backup of config.json from before the issue, and have not yet erased the database, there is a temporary workaround: https://github.com/signalapp/Signal-Desktop/issues/6970#issuecomment-2376825795

The file gets overwritten whenever you launch the app though, so while the issue is ongoing, you gotta restore the file before every launch.

ps: I haven't tried the suggested workarounds in this thread yet; maybe they're better than this temp one, dunno.

[sukahiroaki]

Sorry to ask so bluntly, but: Why is PR #729 not being reverted right now? It's clear that it broke Signal for nearly all users of the Flatpak (At least on GNOME I've yet to encounter anyone where it didn't destroy the local db). And yes, this destruction can't be reverted. But right now you can't use the current stable Flatpak at all, cause it will break again and again after deleting the data and doing a fresh setup. Unless you know one of the tricks to prevent this (like playing around with Flatseal), but this is nothing any regular users will (or should have to) know.

What am I missing?

[minosimo]

I tried the three most recent commits available from the flathub repo:

Commit: 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab - Breaks database key
Parent: cff4c7d3a21c4b7fdbb482f7284d686f821d5e293161a77b88b221ebe40a6542
Subject: Revert "Fix capitalization" (#731) (2837844c)
Date: 2024-09-25 14:56:01 +0000

Commit: cff4c7d3a21c4b7fdbb482f7284d686f821d5e293161a77b88b221ebe40a6542 - Fine
Subject: Fix capitalization (f88079a9)
Date: 2024-09-25 07:00:55 +0000

Commit: 0eda03824f6ef10b2e733b6fe0ed8dc25d01e311eea1ad1c9cb739e8fb50ab1f - Fine
Subject: Use freedesktop 24.08 SDK & runtime (#725) (15d435a1)
Date: 2024-09-24 06:40:02 +0000

The most recent one is just reverting the previous one. I'm probably missing something but how did this cause the database error; why would 295c break, while 0eda doesn't?

Also obvious question, but given that the latest version breaks the app, is there a way to mark that update as bad so it stops getting pushed out to people?

[salim-b]

The most recent one is just reverting the previous one. I'm probably missing something but how did this cause the database error; why would 295c break, while 0eda doesn't?

Are you sure you didn't experience https://github.com/flathub/org.signal.Signal/issues/723#issuecomment-2374911661 ?

[minosimo]

The most recent one is just reverting the previous one. I'm probably missing something but how did this cause the database error; why would 295c break, while 0eda doesn't?

Are you sure you didn't experience #723 (comment) ?

Not sure I understand. When I update to 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab, I experience the database error described in this thread, which is what that comment describes. I got a bit lost between the several commits, reverts, and trying to match up the flathub hashes to github commits.

[salim-b]

Not sure I understand.

The very first time (fresh install / no profile DB), Signal starts fine and writes its key to the keystore (gnome-keyring). The second time Signal starts, it fails to get its key from the keystore again and hence presents the user with a DB corruption error. At least that's what I experienced, same as what @sukahiroaki described in https://github.com/flathub/org.signal.Signal/issues/723#issuecomment-2374911661. So you might also experience this while switching between these revisions, I guessed...

[minosimo]

Not sure I understand.

The very first time (fresh install / no profile DB), Signal starts fine and writes its key to the keystore (gnome-keyring). The second time Signal starts, it fails to get its key from the keystore again and hence presents the user with a DB corruption error. At least that's what I experienced, same as what @sukahiroaki described in #723 (comment). So you might also experience this while switching between these revisions, I guessed...

Specifically, I installed each of those three commits in turn, and re-launched signal several times on each. The database was only unreadable when launching commit 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab several times.

[bermeitinger-b]

Can you start Signal with the --password-store=basic?

We could add this switch as a workaround, so that it at least runs as before (until chromium, electron, and Signal have a fix).

[x80486]

Can you start Signal with the --password-store=basic?

We could add this switch as a workaround, so that it at least runs as before (until chromium, electron, and Signal have a fix).

This is effectively the same as rolling back the commit that introduced the issue — with the bonus of not having people swarming on the issue tracker.

Moreover, there are plenty of Signal users who aren't going to be able to do it or even find out how to do it.

This issue is almost generic for all Electron applications that rely on Electron's safeStorage, regardless of the packaging. It's happening with Wire and many others.

The implementation and fallback mechanism for Signal is quite poor though (my opinion), to the point that the application becomes useless, and the database corrupted.

[minosimo]

Can you start Signal with the --password-store=basic?

We could add this switch as a workaround, so that it at least runs as before (until chromium, electron, and Signal have a fix).

On Fedora GNOME, after going back to the broken version, launching signal twice, then launching with --password-store=basic I get a different database error:

After editing config.json and removing the line "safeStorageBackend": "gnome_libsecret" and replacing the encryptedKey with the key from a backup, it works.

[minosimo]

Can you start Signal with the --password-store=basic? We could add this switch as a workaround, so that it at least runs as before (until chromium, electron, and Signal have a fix).

This is effectively the same as rolling back the commit that introduced the issue — with the bonus of not having people swarming on the issue tracker.

Moreover, there are plenty of Signal users who aren't going to be able to do it or even find out how to do it.

This issue is almost generic for all Electron applications that rely on Electron's safeStorage, regardless of the packaging. It's happening with Wire and many others.

The implementation and fallback mechanism for Signal is quite poor though (my opinion), to the point that the application becomes useless, and the database corrupted.

I can confirm that always starting the broken build with --password-store=basic works just fine, whether that's preferable to reverting #729 I don't know. Where should the flag be added so it is sure to run? Just adding it to the .desktop file would leave the possibility that other .desktop files, ie those created for autostart, would still run signal without the flag.

This issue has existed for four days, but I only got the update on both of my systems today. The sooner a fix is pushed the fewer systems will be borked.

[salim-b]

Where should the flag be added so it is sure to run? Just adding it to the .desktop file would leave the possibility that other .desktop files, ie those created for autostart, would still run signal without the flag.

I think as users we can only add it to the .desktop file(s). flatpak override can't modify command flags (yet) according to https://github.com/flatpak/flatpak/issues/2913. That's why I asked about a possible environment variable. But I guess such a variable simply doesn't exist (did a web search without a result).

Hence I agree that reverting the --talk-name=org.freedesktop.secrets addition would be the sane choice (until the underlying Electron bug(s) are fixed).

[bermeitinger-b]

We could add a custom env var for users to set their own password store and fallback to basic.

[minosimo]

I attempted to add an env var in #738. @bermeitinger-b does this look correct? Would you be able to merge one of the two so this fix gets out quickly?

[bermeitinger-b]

It looks correct.

[Lurux]

I tried the three most recent commits available from the flathub repo:

Commit: 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab - Breaks database key
Parent: cff4c7d3a21c4b7fdbb482f7284d686f821d5e293161a77b88b221ebe40a6542
Subject: Revert "Fix capitalization" (#731) (2837844c)
Date: 2024-09-25 14:56:01 +0000

Commit: cff4c7d3a21c4b7fdbb482f7284d686f821d5e293161a77b88b221ebe40a6542 - Fine
Subject: Fix capitalization (f88079a9)
Date: 2024-09-25 07:00:55 +0000

Commit: 0eda03824f6ef10b2e733b6fe0ed8dc25d01e311eea1ad1c9cb739e8fb50ab1f - Fine
Subject: Use freedesktop 24.08 SDK & runtime (#725) (15d435a1)
Date: 2024-09-24 06:40:02 +0000

The most recent one is just reverting the previous one. I'm probably missing something but how did this cause the database error; why would 295c break, while 0eda doesn't?

Also obvious question, but given that the latest version breaks the app, is there a way to mark that update as bad so it stops getting pushed out to people?

@minosimo you're missing this commit: a33edd142902db474dbe036b6a51190c2a5b90ac Presumably it just got batched with the following one when pulled by Flathub or something ?

Anyways clearly that commit needs reverting.

[minosimo]

We can also just merge the revert now, which will prevent more systems from permanently erasing the desktop conversation history, and add the env variable later.

For anyone whose secret store is working with the latest flathub package, reverting #729 would only temporarily prevent them from launching the desktop app, which will be the case anyway once the environment variable is added.

[toppk]

i will give my recovery instructions. First, my recovery involves having backup, sorry if that excludes you. I don't think my backup was too recent, so take a look. Second there's a bit about database schema in here, that was something that you'll have to be aware of if you're lucky enough to fix the encryption issue. When you downgrade signal to and older version which is prudent until signal.org gives much better clarity how to avoid this issue, you may overshoot and install a version of signal that is incompatible with the database. But you'll see this after you get past the encryption hurdle if it is relevant. I think it's safe to just go back to a early version well before the scary 7.24.2 times, this is because there's a schema check in the code, that you'll see how to deal with in step 6. I won't recommend a version, because i don't understand much about the schema update process, but I went back to a month or so ago version.

1. list old flatpaks with flatpak remote-info --log flathub org.signal.Signal

2. install old flatpaks with flatpak update --commit $COMMIT_VALUE org.signal.Signal this has to be done as root

3. backup your Database existing signal tar -cvzf ~/signal-bu.tgz ~/.var/app/org.signal.Signal (do no harm)

4. Look at your current/backups settings in .var/app/org.signal.Signal/config/Signal/config.json basically replace those bad fields with the good fields and things should be be working again, almost.

   current(BAD)

   "encryptedKey": "not_this_time_NSA",
   "safeStorageBackend": "gnome_libsecret"

   backup(GOOD)

   "key": "not_this_time_NSA",

5. Everything is good and working again, no more Database startup error: SqliteError: file is not a database errors, or...

6. You might see now see this Database startup error: DBVersionFromFutureError: SQL: User version is 1190 but the expected maximum version is 1130. startup error. What I did to correctly go to the minimum required version is just look at this directory and just switch git tags until you find the earliest release that has your needed scema https://github.com/signalapp/Signal-Desktop/tree/v7.24.0/ts/sql/migrations Once you find a version you want repeat steps 1 and 2.

7. Avoid upgrading to the latest version of signal that will likely break the database encryption key again. I am attempting to find out how to permanently keep the unencrypted key or have a successful upgrade, but i don't know of how to do this just yet.

Hopefully this works for you, I am totally shocked that signal and/or flathub hasn't pulled this release, or explained it, because I didn't need to go through this scare. Please warn your friends not to update their flatpak and take an immediately backup of their ~/.var/app/org.signal.Signal directory. credits to @brettk-git @frans-fuerst for adding useful bits of info in other issues that made me feel like a full recovery was possible.

[minosimo]

I have added a warning and some simplified instructions here: https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222

[chinchan54]

I managed to fix it by first doing what @toppk said about reverting the key. Then when updating the Signal flatpak back to 7.24.1 it says this:

New org.signal.Signal permissions:
    dbus access [1]

    [1] org.freedesktop.secrets

So after updating I used Flatseal to remove the "org.freedesktop.secrets" permission and now Signal works on 7.24.1. It seems like this permission changes the key settings in config.json and then Signal can't open the database anymore.

[salim-b]

So after updating I used Flatseal to remove the "org.freedesktop.secrets" permission and now Signal works on 7.24.1. It seems like this permission changes the key settings in config.json and then Signal can't open the database anymore.

Yup. Without the permission, Signal doesn't see the OS keystore and falls back to storing the key in plain-text (field key in ~/.var/app/org.signal.Signal/config/Signal/config.json). If it has the permission to access org.freedesktop.secrets via D-Bus OTOH, it starts to use it (replaces plain-text key with the encrypted encryptedKey and sets the safeStorageBackend in its config), but then fails to re-use those credentials afterwards due to bugs (in the underlying Electron framework, I think; see also https://github.com/electron/electron/issues/32598).

[dominikzogg]

With Gnome 46 it does not work. Other flatpaks using org.freedesktop.secrets (mongodb compass for example) work. Could it be it needs something like https://github.com/flathub/com.mongodb.Compass/blob/master/com.mongodb.Compass.json#L27 ?

[dotbanana]

Signal Desktop on Fedora is basically dead now, all data lost.
Time to finally switch to Matrix.
Good job

[bermeitinger-b]

There is something amiss with Chromium, Electron, and Signal.

It should detect the currently running provider for encrypted storage. For some, this works right away, for some, it doesn't. This is the Chromium/Electron issue.

However, Signal is also at fault here because it believes to have access to an encrypted storage, will migrate the old database to the new key. Unfortunately, it fails saving it correctly. Upon the next start of Signal, it does not receive the correct key and can't decrypt the database.

The current version will fallback to basic (=none) encryption.

You could try renaming the encryptedKey (because Signal does still write the encrypted key to the plaintext file) back to key to check if you can restore the database.

[sukahiroaki]

Can confirm that the latest update now works again without problems for me (with the old, "basic" DB without keyring integration, which is back do being default). Thanks!

Now let's hope someone figures out, what's going on here, cause proper keyring integration would be a big security win (and seems to work fine with other Flatpaks)

[pabl0]

Now let's hope someone figures out, what's going on here, cause proper keyring integration would be a big security win (and seems to work fine with other Flatpaks)

Of course it depends a bit on your threat model. Now that talk-name=org.freedesktop.secrets is the default, I believe it means org.signal.Signal can read any secret from your keyring. For some, it might be worse than storing the Signal database cleartext-at-rest.

[bermeitinger-b]

I don't believe that to be true. It will ask to encrypt/decrypt the db key. Within Electron and its safeStorage, it will create a new "Chromium Safe Storage" entry which will contain the key.

Signal does not query for specific keys and I think it does not have access to the full keyring. I could not find any documentation about this.

Still, seeing that Seahorse can access everything, this is again a matter of trust :woman_shrugging:

[salim-b]

Still, seeing that Seahorse can access everything, this is again a matter of trust 🤷‍♀️

Looking at Key Rack's (modern alternative to Seahorse) Flatpak manifest, it looks like it uses the same means to access the keystore as Signal here does. And Key Rack can of course access the whole keystore once it's unlocked by the user. So I guess a rogue Signal Flatpak could theoretically access the whole keystore, too. But I'm no expert.

[bermeitinger-b]

Obviously, a rogue everything always can do bad stuff.

[pabl0]

Signal does not query for specific keys and I think it does not have access to the full keyring. I could not find any documentation about this.

If I am not mistaken (not too familiar with this), direct access to org.freedesktop.secrets session bus which is granted here, is different to the XDG Portal API that does not expose keys not belonging to the sandboxed app?

Still, seeing that Seahorse can access everything, this is again a matter of trust 🤷‍♀️

Any traditional non-sandboxed GNOME app can access any keyring secret by design, since there is really no meaningful trust separation. At least I tend to trust apps distributed in Flathub slightly less than distro packages simply due to less testing and gatekeeping.

[salim-b]

Obviously, a rogue everything always can do bad stuff.

Not if it isn't given more trust than it deserves. Which is why following a principle of least privilege is wise (but also hard) – which Flatpak (sandboxing), at least in theory, attempts to.

[Cybercountry]

Hello,

Today, when I started my computer and opened Signal Desktop, I encountered an error similar to what has been mentioned in other issues. Last night, I updated to GNOME 47, and this was the first time I restarted the system in a few weeks, also the first time I closed Signal during that period. Initially, I thought the issue might be related to the GNOME update, but I'm not sure.

I tried updating to the latest version of Signal (7.24.1), hoping it would fix the problem, but the error persists. When I start Signal via desktop, I get the following error message:

"Switch to the previous desktop environment or try running Signal with the command-line flag --password-store=gnome-libsecret."

When I run Signal via CLI with the following command:

flatpak run org.signal.Signal --password-store=gnome-libsecret

I receive an error message stating that there was a problem with the database and that I should copy the error and contact support. The message also suggests that if I need to use Signal immediately, I should delete the data and restart the app. This message is different from the one that appears when I open Signal via the desktop.

I’m using Signal Desktop with Flatpak because I currently don't have access to my phone, and Signal is a very important app for me. I just wanted to report this issue in the current version and thank everyone involved in the project. I hope the problem gets resolved soon.

Additionally, I would like to mention that I am using the Flare version of the app, which is an unofficial app for Signal. It is still in development and does not include all the features that the official Signal apps do. More information can be found on its feature roadmap.

Here is a link to a note where I show the output of the command run via CLI: Signal Log

Thank you!

[minosimo]

Hello,

Today, when I started my computer and opened Signal Desktop, I encountered an error similar to what has been mentioned in other issues. Last night, I updated to GNOME 47, and this was the first time I restarted the system in a few weeks, also the first time I closed Signal during that period. Initially, I thought the issue might be related to the GNOME update, but I'm not sure.

I tried updating to the latest version of Signal (7.24.1), hoping it would fix the problem, but the error persists. When I start Signal via desktop, I get the following error message:

"Switch to the previous desktop environment or try running Signal with the command-line flag --password-store=gnome-libsecret."

When I run Signal via CLI with the following command:

flatpak run org.signal.Signal --password-store=gnome-libsecret

I receive an error message stating that there was a problem with the database and that I should copy the error and contact support. The message also suggests that if I need to use Signal immediately, I should delete the data and restart the app. This message is different from the one that appears when I open Signal via the desktop.

I’m using Signal Desktop with Flatpak because I currently don't have access to my phone, and Signal is a very important app for me. I just wanted to report this issue in the current version and thank everyone involved in the project. I hope the problem gets resolved soon.

Additionally, I would like to mention that I am using the Flare version of the app, which is an unofficial app for Signal. It is still in development and does not include all the features that the official Signal apps do. More information can be found on its feature roadmap.

Here is a link to a note where I show the output of the command run via CLI: Signal Log

Thank you!

Unfortunately, unless you have a backup of your database key, the chat history is most likely gone from your desktop. https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222

There may be a way to restore the key, though I may also have misunderstood how this works https://github.com/signalapp/Signal-Desktop/issues/6944#issuecomment-2259575767