Database Error #723

rdong8 · 2024-09-22T18:05:10Z

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

sukahiroaki · 2024-09-25T18:54:09Z

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 · 2024-09-25T19:08:46Z

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 · 2024-09-25T19:15:10Z

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 · 2024-09-25T19:24:37Z

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 · 2024-09-25T19:35:13Z

Thank you! 🙏 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 · 2024-09-25T20:44:53Z

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 · 2024-09-25T20:55:17Z

I'm using gnome-keyring version 46.2

salim-b · 2024-09-25T22:32:03Z

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 · 2024-09-26T06:30:55Z

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 · 2024-09-26T09:33:25Z

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 · 2024-09-26T09:50:00Z

I have the same issue, see here #729 (comment) :(

konomikitten · 2024-09-26T10:11:43Z

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

bermeitinger-b · 2024-09-26T12:53:04Z

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 · 2024-09-26T14:03:19Z

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 · 2024-09-26T14:05:19Z

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 · 2024-09-26T14:07:13Z

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 · 2024-09-26T15:13:05Z

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 · 2024-09-26T16:47:38Z

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: signalapp/Signal-Desktop#6970 (comment)

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 · 2024-09-26T18:09:00Z

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 · 2024-09-26T18:09:27Z

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 · 2024-09-26T18:25:48Z

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

minosimo · 2024-09-26T18:29:03Z

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 · 2024-09-26T18:42:46Z

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

minosimo · 2024-09-26T18:44:24Z

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 · 2024-09-26T18:55:36Z

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 · 2024-09-26T19:05:29Z

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 · 2024-09-26T19:07:41Z

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 · 2024-09-26T19:23:44Z

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.

distbit0 · 2024-09-29T23:22:10Z

I managed to resolve this due to finding an unintentional backup of my config file located at ~/.config/Signal/config.json from when I used to use a non-flatpak version of Signal, whereas my current config file (which only conatined the encrypted key) is located at ~/.var/app/org.signal.Signal/config/Signal/config.json.

This may be helpful to anyone who previously used a non-flatpak signal package before switching to flatkpak, or vice versa, due to different package formats using different config file paths.

woodsb02 · 2024-09-29T23:32:23Z

I managed to resolve it because I realised I take regular file system snapshots using ZFS, and was able to find the backup of the file in ~/.config/ from earlier in the day before the upgrade.

ErrorTeaPot · 2024-10-01T06:19:12Z

Any updates for this issue ?

kkmaslowski · 2024-10-01T06:29:32Z

For me helped switching back to basic store (previous version used it):
flatpak override org.signal.Signal --user --env=SIGNAL_PASSWORD_STORE=basic

minosimo · 2024-10-01T09:17:41Z

Any updates for this issue ?

You can be sure that when there is progress, it will be posted. The PR that re-enables (the use of) gnome-libsecret (on GNOME) is here: #756

bermeitinger-b · 2024-10-01T10:57:30Z

The PR tries to fix an issue with libsecret. It does not "enable" gnome-libsecret.

techrivertree · 2024-10-03T13:06:52Z

I am seeing the same database error on my desktop comp however, signal desktop on my latptop still works. Can I, backup the chat history on my laptop to restore chat history on my desktop whenever signal desktop works again? I am using Zorin OS Pro (Ubuntu fork) on both comps.

wie-was · 2024-10-04T17:52:42Z

Having the same issue, cannot use Signal on Desktop anymore since weeks. I don't want to delete the database, because some messages are only stored on my computer, not on my phone.

gabrc52 · 2024-10-05T22:30:24Z

Does this sound true?

pabl0 · 2024-10-06T07:45:48Z

Does this sound true?

I have no idea, but I would definitely make a backup copy of the whole ~/.var/app/org.signal.Signal/ tree just in case, before doing anything else. Maybe there is hope after all.

carpediem29 · 2024-10-07T13:13:38Z

With secret-tool we can identify the password but it's encoded see #753) .
Not sure how we can decode the value properly.

wie-was · 2024-10-10T19:19:51Z

Does this sound true?

Any update on this? 🤓

gabrc52 · 2024-10-10T20:15:58Z

No clue :( it might be genuinely impossible to recover. I'm just waiting until the day Signal will magically start working again until there is a new update is released to the Flatpak and just use my phone in the meantime, but it is possible that it was broken enough that the encryption key was never stored anywhere (which is what seems to be implied) so in the absence of a backup, it might be impossible to recover. I am also waiting to see if I have the time and energy to find a backup, but I haven't found any backup.

I think this is a sign for everyone to backup your home folder using filesystem snapshots or something like https://apps.gnome.org/PikaBackup/

minosimo · 2024-10-11T21:46:44Z

With secret-tool we can identify the password but it's encoded see #753) . Not sure how we can decode the value properly.

Use Key Rack. The key in Signal > Chromium Safe Storage in Key Rack should be the decryption key for the encryptedKey in config.json, but I have yet to get it to work.

gabrc52 · 2024-10-12T00:32:32Z

That's great news! I do see the key in there, so it has not been lost to the void; thank you for recommending Key Rack!

minosimo · 2024-10-12T09:18:18Z

That's great news! I do see the key in there, so it has not been lost to the void; thank you for recommending Key Rack!

Some more complete instructions that should recover the message history:

Open Key Rack, click Signal (2 keys), open Chromium Safe Storage, and copy the key.
Add it to the normal keyring with secret-tool store --label "Chromium Safe Storage" application Signal. When it asks for a password, paste the key.
Install Signal from Build libsecret without gcrypt #756 (scroll down to the bottom for the latest build)
Check that ~/.var/app/org.signal.Signal/config/Signal/config.json has an "encryptedKey" entry
Set signal to launch with gnome-libsecret via Flatseal, or run flatpak override org.signal.Signal --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret
Run signal from the terminal, flatpak run org.signal.Signal//test, check the output to confirm it's using gnome-libsecret

For me this does not work, but I don't see why it wouldn't, so testing help is very appreciated!

carpediem29 · 2024-10-13T12:20:03Z

I didn't work for me. Maybe because I had 2 signal versions installed :
1) app/org.signal.Signal/x86_64/stable (system) 2) app/org.signal.Signal/x86_64/test (user)

I backuped my $HOME/.var/app/org.signal.Signal prior to the process you describe so I can try another process/give it another try.

minosimo · 2024-10-13T16:30:22Z

Thanks for testing. The two versions are expected. So far this hasn't worked for anybody, so my assumption about the key written by the broken update must be wrong. The next step would be to recreate a fresh install, note the plaintext key, move to the bad update, note what gets written to the file based flatpak key, and compare with what gets written by the build in this PR.

Cybercountry · 2024-10-16T14:46:09Z

Hello, @minosimo
I noticed that in the new update of Signal available on Flathub, it asks for additional permissions for the file system.
Since the last time I managed to resolve the issue, I haven't updated my app. This might sound like a silly question, but I'd like to know if it's "safe" to update now.
Thanks!

toppk · 2024-10-17T22:26:47Z

Hello, @minosimo I noticed that in the new update of Signal available on Flathub, it asks for additional permissions for the file system. Since the last time I managed to resolve the issue, I haven't updated my app. This might sound like a silly question, but I'd like to know if it's "safe" to update now. Thanks!

i'm using it, and it works fine, the default of plaintext keys is documented as the default. but of course, you should take a backup and ensure you know how your existing signal is configured, with respect to the database encryption key.

avigua · 2024-10-20T17:34:17Z

Quite new to this (my Signal broke in 7.24 and haven't been able to recover it yet). Before I do any updates and give the additional permissions, can someone point me to or explain why this new permissions are required and how are they different from what signal had before, and if it's a 'good idea' to give these extra permissions? Thanks (basically worried about giving further access to my root system)

Also, I don't understand what the explanation means on the popup window after the update is installed (but before conceding to the additional permissions, see image). I don't know what permissions to give using Flatseal, and so I'm going in blind if I just say 'yes' at this step.

minosimo · 2024-10-20T18:24:30Z

The new permissions are unrelated to the database issue. The links in your screenshot do a good job of explaining why the change was implemented.

#719

electron/electron#43819 (comment)

Sebsdnl · 2024-10-24T23:05:46Z

Problem persist on 7.30

sojusnik · 2024-10-26T07:48:54Z

For me helped switching back to basic store (previous version used it): flatpak override org.signal.Signal --user --env=SIGNAL_PASSWORD_STORE=basic

~~In my case, Ubuntu with Gnome, the following helps on Signal 7.30.0: flatpak override org.signal.Signal --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret~~ False positive! Database issue still present on 7.30.

minosimo · 2024-10-26T08:02:50Z

@Sebsdnl @sojusnik Please see here for troubleshooting.

https://community.signalusers.org/t/troubleshooting-guide-database-error-after-flatpak-update-from-flathub/63222/35

mftcodes · 2024-11-03T23:32:45Z

Just running into this on 7.31.0

Cinnamon3431 · 2024-12-11T15:46:29Z

god bless I found this thread, I was going nuts trying to figure out why it kept and kept on breaking, I thought it had something to do with me creating new users under fedora gnome... guess I'll try to tinker around with some of the mentioned workarounds until a fix is on the horizon.... :(

Altonss mentioned this issue Sep 26, 2024

Signal desktop suddenly crashes on Ubuntu 24.04.1 Wayland #736

Closed

Altonss mentioned this issue Sep 26, 2024

signal-desktop won't start after upgrade to 7.24.X (and sudo user pw change) signalapp/Signal-Desktop#7018

Open

2 tasks

Altonss mentioned this issue Sep 30, 2024

Signal encryption keyring changed from gnome_libsecret to basic_text #753

Open

XenonSup mentioned this issue Oct 21, 2024

Database Error after update to 7.29 #774

Closed

czhang03 mentioned this issue Nov 4, 2024

GitHub Extension Requests Authentication Every Time on Gnome flathub/com.vscodium.codium#379

Closed

Database Error #723

Database Error #723

Comments

rdong8 commented Sep 22, 2024

sukahiroaki commented Sep 25, 2024

sukahiroaki commented Sep 25, 2024

Greenheart commented Sep 25, 2024 • edited Loading

sukahiroaki commented Sep 25, 2024

Greenheart commented Sep 25, 2024 • edited Loading

bermeitinger-b commented Sep 25, 2024

Greenheart commented Sep 25, 2024 • edited Loading

salim-b commented Sep 25, 2024 • edited Loading

bermeitinger-b commented Sep 26, 2024

konomikitten commented Sep 26, 2024

Altonss commented Sep 26, 2024

konomikitten commented Sep 26, 2024

bermeitinger-b commented Sep 26, 2024 • edited Loading

mkhl commented Sep 26, 2024

x80486 commented Sep 26, 2024

konomikitten commented Sep 26, 2024 • edited Loading

caseybecking commented Sep 26, 2024

TiagoTiago commented Sep 26, 2024

sukahiroaki commented Sep 26, 2024

minosimo commented Sep 26, 2024 • edited Loading

salim-b commented Sep 26, 2024

minosimo commented Sep 26, 2024 • edited Loading

salim-b commented Sep 26, 2024

minosimo commented Sep 26, 2024

bermeitinger-b commented Sep 26, 2024

x80486 commented Sep 26, 2024

minosimo commented Sep 26, 2024 • edited Loading

minosimo commented Sep 26, 2024

distbit0 commented Sep 29, 2024

woodsb02 commented Sep 29, 2024

ErrorTeaPot commented Oct 1, 2024

kkmaslowski commented Oct 1, 2024

minosimo commented Oct 1, 2024 • edited Loading

bermeitinger-b commented Oct 1, 2024

techrivertree commented Oct 3, 2024

wie-was commented Oct 4, 2024

gabrc52 commented Oct 5, 2024

pabl0 commented Oct 6, 2024

carpediem29 commented Oct 7, 2024 • edited Loading

wie-was commented Oct 10, 2024

gabrc52 commented Oct 10, 2024

minosimo commented Oct 11, 2024

gabrc52 commented Oct 12, 2024

minosimo commented Oct 12, 2024

carpediem29 commented Oct 13, 2024 • edited Loading

minosimo commented Oct 13, 2024

Cybercountry commented Oct 16, 2024

toppk commented Oct 17, 2024

avigua commented Oct 20, 2024 • edited Loading

minosimo commented Oct 20, 2024

Sebsdnl commented Oct 24, 2024

sojusnik commented Oct 26, 2024 • edited Loading

minosimo commented Oct 26, 2024

mftcodes commented Nov 3, 2024

Cinnamon3431 commented Dec 11, 2024

Greenheart commented Sep 25, 2024 •

edited

Loading

Greenheart commented Sep 25, 2024 •

edited

Loading

Greenheart commented Sep 25, 2024 •

edited

Loading

salim-b commented Sep 25, 2024 •

edited

Loading

bermeitinger-b commented Sep 26, 2024 •

edited

Loading

konomikitten commented Sep 26, 2024 •

edited

Loading

minosimo commented Sep 26, 2024 •

edited

Loading

minosimo commented Sep 26, 2024 •

edited

Loading

minosimo commented Sep 26, 2024 •

edited

Loading

minosimo commented Oct 1, 2024 •

edited

Loading

carpediem29 commented Oct 7, 2024 •

edited

Loading

carpediem29 commented Oct 13, 2024 •

edited

Loading

avigua commented Oct 20, 2024 •

edited

Loading

sojusnik commented Oct 26, 2024 •

edited

Loading