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.

DennisBauer · 2024-09-27T16:00:02Z

@Cybercountry just copy the content of the

/home/USER/.var/app/org.signal.Signal/config/Signal/config.json

from your backup to your current directory and re-launch Signal. Make sure you're using the latest flatpak version of the app before opening it.

Cybercountry · 2024-09-27T16:02:40Z

Make sure you're using the latest flatpak version of the app before opening it.

So should I do this with the latest Signal update available on flathub (7.24.1)? Should I not rollback?

DennisBauer · 2024-09-27T16:03:39Z

The latest version already revered the commit introducing this issue. 7.24.1 works fine for me.

Cybercountry · 2024-09-27T16:05:15Z

The latest version already revered the commit introducing this issue. 7.24.1 works fine for me.

Alright, I'll test it.

minosimo · 2024-09-27T16:05:21Z

The version number is not enough to know which build is installed. Check the link I posted for instructions

flatpak info org.signal.Signal

If you see Commit: 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab, you have the bad version. Any other commit is ok.

Cybercountry · 2024-09-27T16:12:47Z

@minosimo Amazing! It worked. Thank you so much for the help!

Are there any precautions I should take from now on until the issue is fully resolved, like avoiding updates or anything like that? Or is everything safe to proceed as usual?

Thanks again!

minosimo · 2024-09-27T16:15:36Z

@minosimo Amazing! It worked. Thank you so much for the help!

Are there any precautions I should take from now on until the issue is fully resolved, like avoiding updates or anything like that? Or is everything safe to proceed as usual?

Thanks again!

Glad to hear it! You can check the output of flatpak remote-info --log flathub org.signal.Signal, scroll to the top and look at which commits are available. As long as 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab is not the most recent commit, you are ok to keep updating.

Cybercountry · 2024-09-27T16:22:15Z

@minosimo Amazing! It worked. Thank you so much for the help!
Are there any precautions I should take from now on until the issue is fully resolved, like avoiding updates or anything like that? Or is everything safe to proceed as usual?
Thanks again!

Glad to hear it! You can check the output of flatpak remote-info --log flathub org.signal.Signal, scroll to the top and look at which commits are available. As long as 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab is not the most recent commit, you are ok to keep updating.

Here is the output of the command with the first three commits:

   Commit: a86572347a1f1567a4415637c6488a1951dc48304366146de9eecce3b…
      Parent: 0b6293197e181c49a1f2917a6ecce91c3f22849939782cfd84a1033b2…
  Subject: Show encryption notification only once (#744) (c1bc7881)
     Date: 2024-09-27 11:45:29 +0000
History: 

   Commit: 0b6293197e181c49a1f2917a6ecce91c3f22849939782cfd84a1033b22b26528
  Subject: Show encryption notification only once (#744) (c1bc7881)
     Date: 2024-09-27 11:35:18 +0000

   Commit: 04fd9bd67d62470c5ac36ab247e0f7ad2fe9b858d84a15ef09654afdb70f00c7
  Subject: Add environment variable to select storage provider (#741) (0b347f5a)
     Date: 2024-09-27 09:59:01 +0000

Should I use the command flatpak update --no-related org.signal.Signal to prevent Signal from updating automatically?

And when I decide to update manually, should I rerun the flatpak remote-info --log flathub org.signal.Signal command to check if the problematic commit is among the most recent ones?

Also, is there any other precaution I should take to ensure I avoid this issue in the future?

minosimo · 2024-09-27T16:25:13Z

@minosimo Amazing! It worked. Thank you so much for the help!
Are there any precautions I should take from now on until the issue is fully resolved, like avoiding updates or anything like that? Or is everything safe to proceed as usual?
Thanks again!

Glad to hear it! You can check the output of flatpak remote-info --log flathub org.signal.Signal, scroll to the top and look at which commits are available. As long as 295cc3f0e266ecec6a0971cbfeb8559c18d0a12d51116680aa241ec34471afab is not the most recent commit, you are ok to keep updating.

Here is the output of the command with the first three commits:
   Commit: a86572347a1f1567a4415637c6488a1951dc48304366146de9eecce3b…
      Parent: 0b6293197e181c49a1f2917a6ecce91c3f22849939782cfd84a1033b2…
  Subject: Show encryption notification only once (#744) (c1bc7881)
     Date: 2024-09-27 11:45:29 +0000
History: 

   Commit: 0b6293197e181c49a1f2917a6ecce91c3f22849939782cfd84a1033b22b26528
  Subject: Show encryption notification only once (#744) (c1bc7881)
     Date: 2024-09-27 11:35:18 +0000

   Commit: 04fd9bd67d62470c5ac36ab247e0f7ad2fe9b858d84a15ef09654afdb70f00c7
  Subject: Add environment variable to select storage provider (#741) (0b347f5a)
     Date: 2024-09-27 09:59:01 +0000
Should I use the command flatpak update --no-related org.signal.Signal to prevent Signal from updating automatically?

And when I decide to update manually, should I rerun the flatpak remote-info --log flathub org.signal.Signal command to check if the problematic commit is among the most recent ones?

Also, is there any other precaution I should take to ensure I avoid this issue in the future?

If you look lower you will see the problematic commit. The three you listed all come after the problematic one, so you are ok to keep updating.

You can always delay updates and update manually after some time has passed. I have always had auto-updates on, but after this I will probably opt for manual updates instead.

Cybercountry · 2024-09-27T16:26:59Z

@minosimo Thank you very much again! Have a great day!

minosimo · 2024-09-28T17:39:29Z

I have updated troubleshooting instructions here: https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222

If you need help, please ask in that thread rather than on github.

flaphoschi · 2024-09-29T09:21:17Z

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

Hello!
Thanks for the revert.

Please add that to the release notes of the Flatpak package on Flathub! It is not sufficient to state that just on Github.
Please bump the version number of Signal with every package update e.g 7.24.1-1, 7.24.1-2, 7.24.1-3.

Thank you

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!

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

moedn mentioned this issue Sep 29, 2024

Error: Error while decrypting the ciphertext provided to safeStorage.decryptString. signalapp/Signal-Desktop#7005

Open

2 tasks

Altonss mentioned this issue Sep 30, 2024

Signal encryption keyring changed from gnome_libsecret to basic_text #753

Open

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

DennisBauer commented Sep 27, 2024

Cybercountry commented Sep 27, 2024

DennisBauer commented Sep 27, 2024

Cybercountry commented Sep 27, 2024

minosimo commented Sep 27, 2024

Cybercountry commented Sep 27, 2024

minosimo commented Sep 27, 2024

Cybercountry commented Sep 27, 2024

minosimo commented Sep 27, 2024

Cybercountry commented Sep 27, 2024

minosimo commented Sep 28, 2024

flaphoschi commented Sep 29, 2024 • edited Loading

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

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

flaphoschi commented Sep 29, 2024 •

edited

Loading

minosimo commented Oct 1, 2024 •

edited

Loading

carpediem29 commented Oct 7, 2024 •

edited

Loading