Build libsecret without gcrypt #756

bbhtt · 2024-09-29T11:08:38Z

If you previously had basic storage, run it as flatpak run --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal and check if it's storing in the keyring correctly.

flathubbot · 2024-09-29T11:09:43Z

Started test build 150490

flathubbot · 2024-09-29T11:16:27Z

Build 150490 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/133582/org.signal.Signal.flatpakref

minosimo · 2024-09-29T11:31:35Z

On Fedora 40 this works.

minosimo · 2024-09-29T11:48:29Z

We should use the keyring as default again, and if it's possible, also recover the key from the app_id org.signal.Signal entry if it exists.

salim-b · 2024-09-29T11:49:23Z

Nice! With this change, SIGNAL_PASSWORD_STORE=gnome-libsecret now works for me on Ubuntu 22.04 (gnome-keyring: 40.0).

secret-tool search application Signal now gives:

[/45]
label = Chromium Safe Storage
secret = yadayadayada
created = 2024-09-29 11:43:38
modified = 2024-09-29 11:43:38
schema = chrome_libsecret_os_crypt_password_v2
attribute.application = Signal

Does that mean, the underlying issue was on the libsecret side of things and not Electron's or Signal's fault?

bermeitinger-b · 2024-09-29T12:24:42Z

It's nice that it's working.

If it was not working with Gnome before, what's the point of flatpak? It's supposed to be agnostic and be able to run anywhere.

Doesn't Ubuntu provide this library, or is it outdated maybe?

I recommend a bit more testing, especially without the env var and its checking, so that it defaults to use the keyring if available, just like upstream.

salim-b · 2024-09-29T12:31:20Z

If it was not working with Gnome before, what's the point of flatpak? It's supposed to be agnostic and be able to run anywhere.

I guess this is just yet another part that is not (yet) agnostic.

Doesn't Ubuntu provide this library, or is it outdated maybe?

> apt info libsecret-1-0
Package: libsecret-1-0
Version: 0.20.5-2
Priority: optional
Section: libs
Source: libsecret
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 439 kB
Depends: libc6 (>= 2.14), libgcrypt20 (>= 1.9.0), libglib2.0-0 (>= 2.59.0), libsecret-common
Breaks: seahorse (<< 3.10)
Homepage: https://wiki.gnome.org/Projects/Libsecret
Task: ubuntu-desktop-minimal, ubuntu-desktop, ubuntu-desktop-raspi, kubuntu-desktop, kubuntu-full, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi
Download-Size: 124 kB
APT-Manual-Installed: yes
APT-Sources: http://ch.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
Description: Secret store
 Library for storing and retrieving passwords and other secrets.
 It communicates with the "Secret Service" using DBus.

bbhtt · 2024-09-29T12:31:31Z

libsecret uses a file based backend inside Flatpak specifically which is incompatible with how Chromium tries to use it. Disabling this compiles out that backend and it reverts to the usual DBus backend same as how it works outside Flatpak.

We should use the keyring as default again, and if it's possible, also recover the key from the app_id org.signal.Signal entry if it exists.

I don't think it's possible to do that

bbhtt · 2024-09-29T12:36:18Z

The library was already present through the electron baseapp btw but it isn't compiled with -Dgcrypt=false, it uses the upstream default.

salim-b · 2024-09-29T13:49:45Z

Great research @bbhtt, I guess!

libsecret uses a file based backend inside Flatpak specifically which is incompatible with how Chromium tries to use it.

Are the upstream (Electron/Chromium) devs aware of this?

The library was already present through the electron baseapp btw but it isn't compiled with -Dgcrypt=false, it uses the upstream default.

With "electron baseapp", you're referring to this repo? Any specific reason to not add the -Dgcrypt=false compilation flag to this base app rather than Signal here?

flathubbot · 2024-09-29T13:50:42Z

Started test build 150509

bbhtt · 2024-09-29T13:53:45Z

I don't know if chromium/electron developers are aware, but libsecret has an issue open for a long time https://gitlab.gnome.org/GNOME/libsecret/-/issues/49 The fix is for Chromium to use the proper API.

With "electron baseapp", you're referring to this repo? Any specific reason to not add the -Dgcrypt=false compilation flag to this base app rather than Signal here?

There is no migration path between the backends, switching the backend will mean the app cannot retrieve the secrets anymore.

Electron baseapp was using gcrypt backend ever since its inception. Disabling it now and switching it will break any app that depends on it.

It doesn't matter for signal because it was using plain text before.

flathubbot · 2024-09-29T13:57:22Z

Build 150509 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/133602/org.signal.Signal.flatpakref

This uses the Dbus backend instead of the file based ones under Flatpak

flathubbot · 2024-09-29T15:29:23Z

Started test build 150532

pm4rcin · 2024-09-29T15:33:31Z

Not sure if it's related but Tutanota Flatpak that's based on Electron creates dummy entry in keyring because of the bug in Chromium. Not sure if it's related to this bug but here's the text of the entry:

Because of quirks in the gnome libsecret API, Chrome needs to store a dummy entry to guarantee that this keyring was properly unlocked. More details at http://crbug.com/660005.

bbhtt · 2024-09-29T15:34:43Z

No that's unrelated.

flathubbot · 2024-09-29T15:34:55Z

Build 150532 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/133625/org.signal.Signal.flatpakref

salim-b · 2024-09-29T19:18:15Z

I don't know if chromium/electron developers are aware, but libsecret has an issue open for a long time https://gitlab.gnome.org/GNOME/libsecret/-/issues/49 The fix is for Chromium to use the proper API.

The relevant discussion (this thread) happended almost 3 years ago. There was no further activity in the issue after that. Hence I'd consider it plausible that Chromium/Electron development never got a scent of this...

rugk · 2024-09-30T20:57:57Z

So then open an issue with Electron or what is preventing you from doing that?

I don't know the technical details well enough here to describe the problem, so it would be great if one of you could do it.

salim-b · 2024-09-30T22:07:11Z

So then open an issue with Electron or what is preventing you from doing that?

Expertness, mainly. But I tried my best: https://issues.chromium.org/issues/370535829 (the original culprit is Chromium, not Electron, if I'm not mistaken).

ramcq · 2024-09-30T22:11:35Z

@bbhtt This works here. Thanks v. much!

BentHaase · 2024-10-01T10:02:53Z

@bbhtt Works for me, F40 👍

bermeitinger-b · 2024-10-01T10:59:21Z

What makes me wonder is, why this only breaks on Gnome. I'm using gnome-libsecret (i3) and the database works. So this Chromium/Electron misbehavior does not surface on other WMs/DMs.

If Chromium fails, this should I break on all the host systems.

hadess · 2024-10-02T08:31:19Z

I'm a bit lost with all the password backends. I have a simple question though, how do I get back the years of messages that were in the app's cache just last week? And if this requires fishing in backups, what's the path for the file that contains the secret we need to restore, and where do we need to restore it?

ramcq · 2024-10-02T08:38:31Z

Hi @hadess! Hope all is well. What worked for me:

Switch to this package, it will make libsecret work properly and allow Chromium/Electron to speak to GNOME Keyring
Set flatpak override --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal to back out the workaround of going to plaintext stores
Fetch an old enough version of ~/.var/app/org.signal.Signal/config/Signal/config.json from your backup (a couple of weeks ago) and reinstate it - you want one which looks like this:

// GOOD CONFIG - has the key in plaintext, pre keyring-migration
{
  "key": "64_characters_here",
}

If it looks like this, this is post broken migration, and you need to get an older backup - it doesn't matter how old, it's just the key we want, which won't have changed:

// BROKEN CONFIG - migration has occurred, but if it was done with a buggy Electron+libsecret combo, your key wasn't written anywhere
{
  "mediaPermissions": true,
  "encryptedKey": "giant_string_of_numbers_and_letters_here",
  "safeStorageBackend": "gnome_libsecret"
}

(the last bit from upstream at https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222#p-251892-database-error-a-database-error-has-occurred-6 )

And you should be all set. When you run Signal, it will migrate that plaintext key into keyring, and it will be able to access your encrypted db again.

hadess · 2024-10-02T08:43:19Z

Thanks @ramcq, now to test the restore portion of those backups...

salim-b · 2024-10-02T08:45:25Z

What makes me wonder is, why this only breaks on Gnome. I'm using gnome-libsecret (i3) and the database works. So this Chromium/Electron misbehavior does not surface on other WMs/DMs.

What distro are you on? Your system missing the necessary secret portal would explain why libsecret's file backend isn't used (like it is on Gnome).

The conditions under which libsecret prefers its file backend (compiled out by this PR) are found here in the source.

salim-b · 2024-10-02T09:22:33Z

@bbhtt Correct me if I'm wrong. I skimmed over flatpak/xdg-desktop-portal#359 and the related changes and discussions and I think I understand the situation better now:

The recommended way for Flatpaks to use the host's gnome-keyring is actually to not have the --talk-name=org.freedesktop.secrets permission as in #729 (which gives full access to the host's keyring) but instead rely on the secrets portal, which only stores a dedicated master secret for the Flatpak app in the host's keyring and only exposes that very secret to the sandboxed app, which then is used by libsecret's file-based backend inside the sandbox to encrypt the app's actual secrets. That way the libsecret API works transparently for the app in a secure way (encrypted secrets) while not giving it access to the host's whole keystore. The relevant source code part of libsecret is found here.

Unfortunately, this requires the app to use libsecret's SecretRetrievable interface instead of SecretItem, as was discussed several years ago.

I added a comment about this to my Chromium bug report.

bbhtt · 2024-10-02T09:28:37Z

Yes Chromium/Electron needs to transition to using the secrets portal, until that is done they need the org.freedesktop.Secrets access.

hadess · 2024-10-02T10:53:27Z

Fetch an old enough version of ~/.var/app/org.signal.Signal/config/Signal/config.json from your backup (a couple of weeks ago) and reinstate it - you want one which looks like this:

I have one from (gasp) last year, but it doesn't work. It migrates the old key to the encryptedKey format, but fails to open the database.

(only good thing out of this is that it forced me into root causing why my backups weren't working:
https://gitlab.gnome.org/GNOME/gvfs/-/issues/766)

ramcq · 2024-10-02T11:04:08Z

I have one from (gasp) last year, but it doesn't work. It migrates the old key to the encryptedKey format, but fails to open the database.

Ruh roh. If you check in Seahorse and search Chromium Safe Storage, do you see a secret there with "application: Signal" under Details? That's the sign of a happy migration. If the key has migrated, and doesn't work, I don't understand what's happened. The recovery might have to be, set your current db aside, and restore the db that matches the key from the most recent backup you have. Signal should on the whole be able to resync missing history off your phone, but equally, not a Signal guru - I don't know what might be missing after that process.

salim-b · 2024-10-02T11:15:23Z

Signal should on the whole be able to resync missing history off your phone

No, Signal has no support for this (yet), see this forum thread.

Altonss · 2024-10-02T11:23:14Z

I have one from (gasp) last year, but it doesn't work. It migrates the old key to the encryptedKey format, but fails to open the database.

That's because the migration to use gnome-libsecret is failing, keep using SIGNAL_PASSWORD_STORE=basic and it should work fine (except if you are trying the changes developped in this branch).

ramcq · 2024-10-02T11:24:36Z

(except if you are trying the changes developped in this branch)

That's the idea... #756 (comment)

Altonss · 2024-10-02T11:30:09Z

That's the idea... #756 (comment)

I know, but I'm not sure it is what @hadess tried :)

hadess · 2024-10-02T12:09:24Z

I know, but I'm not sure it is what @hadess tried :)

I tested the exact steps @ramcq mentioned, all using the //test build in this PR. I also tried restoring the config.json from backup, deleting the gnome-keyring entry that shows up in seahorse and secret-tool search application Signal, and starting the app again.

It's very possible that the DB is toast from previous attempts.

Log output

Debug: Using password store: gnome-libsecret
Debug: Will run signal with the following arguments: --password-store=gnome-libsecret
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 classic
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/hadess/.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
Gtk-Message: 14:06:17.500: Failed to load module "canberra-gtk-module"
Gtk-Message: 14:06:17.500: Failed to load module "pk-gtk-module"
Gtk-Message: 14:06:17.501: Failed to load module "canberra-gtk-module"
Gtk-Message: 14:06:17.502: Failed to load module "pk-gtk-module"
{"level":30,"time":"2024-10-02T12:06:18.191Z","msg":"got fast localeOverride setting null"}
{"level":30,"time":"2024-10-02T12:06:18.193Z","msg":"app.ready: hour cycle preference: UnknownPreference"}
{"level":30,"time":"2024-10-02T12:06:18.193Z","msg":"app.ready: preferred system locales: en-GB, en"}
{"level":30,"time":"2024-10-02T12:06:18.194Z","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-10-02T12:06:18.194Z","msg":"locale: Preferred locales: en-GB, en"}
{"level":30,"time":"2024-10-02T12:06:18.194Z","msg":"locale: Locale Override: null"}
{"level":30,"time":"2024-10-02T12:06:18.199Z","msg":"locale: Matched locale: en"}
{"level":40,"time":"2024-10-02T12:06:18.285Z","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-10-02T12:06:18.286Z","msg":"locale: Text info direction for en: ltr"}
{"level":30,"time":"2024-10-02T12:06:18.287Z","msg":"getSQLKey: migrating key"}
{"level":30,"time":"2024-10-02T12:06:18.287Z","msg":"getSQLKey: updating encrypted key in the config"}
{"level":30,"time":"2024-10-02T12:06:18.290Z","msg":"config/set: Saving user config to disk"}
{"level":30,"time":"2024-10-02T12:06:18.309Z","msg":"config/set: Saved user config to disk"}
{"level":30,"time":"2024-10-02T12:06:18.310Z","msg":"config/set: Saving user config to disk"}
{"level":30,"time":"2024-10-02T12:06:18.324Z","msg":"config/set: Saved user config to disk"}
{"level":30,"time":"2024-10-02T12:06:18.324Z","msg":"getSQLKey: saving safeStorageBackend: gnome_libsecret"}
{"level":30,"time":"2024-10-02T12:06:18.325Z","msg":"config/set: Saving user config to disk"}
{"level":30,"time":"2024-10-02T12:06:18.336Z","msg":"config/set: Saved user config to disk"}
{"level":30,"time":"2024-10-02T12:06:18.338Z","msg":"getSystemTraySetting got value DoNotUseSystemTray"}
{"level":30,"time":"2024-10-02T12:06:18.338Z","msg":"getSystemTraySetting returning DoNotUseSystemTray"}
{"level":30,"time":"2024-10-02T12:06:18.342Z","msg":"app ready"}
{"level":30,"time":"2024-10-02T12:06:18.343Z","msg":"starting version 7.24.1"}
{"level":30,"time":"2024-10-02T12:06:18.343Z","msg":"media access status [object Undefined] [object Undefined]"}
{"level":30,"time":"2024-10-02T12:06:18.348Z","msg":"got fast theme-setting value light"}
{"level":30,"time":"2024-10-02T12:06:18.379Z","msg":"got fast theme-setting value light"}
{"level":30,"time":"2024-10-02T12:06:18.379Z","msg":"got fast spellcheck setting true"}
{"level":30,"time":"2024-10-02T12:06:18.383Z","msg":"Initializing BrowserWindow config: {\"show\":false,\"width\":3440,\"height\":1371,\"minWidth\":300,\"minHeight\":200,\"autoHideMenuBar\":false,\"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\":69}"}
2024-10-02 14:06:18.502: ERROR CORE sqlcipher_page_cipher: hmac check failed for pgno=1
2024-10-02 14:06:18.503: ERROR CORE sqlite3Codec: error decrypting page 1 data: 1
2024-10-02 14:06:18.503: ERROR CORE sqlcipher_codec_ctx_set_error 1
{"level":30,"time":"2024-10-02T12:06:18.503Z","msg":"spellcheck: user locales: [\"en-GB\",\"en\"]"}
{"level":30,"time":"2024-10-02T12:06:18.503Z","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-10-02T12:06:18.504Z","msg":"spellcheck: setting languages to: [\"en-GB\",\"en\"]"}
2024-10-02 14:06:18.504: ERROR CORE sqlcipher_page_cipher: hmac check failed for pgno=1
2024-10-02 14:06:18.504: ERROR CORE sqlite3Codec: error decrypting page 1 data: 1
2024-10-02 14:06:18.504: ERROR CORE sqlcipher_codec_ctx_set_error 1
{"level":40,"time":"2024-10-02T12:06:18.505Z","msg":"MainSQL: Database log code=26: file is not a database in \"PRAGMA journal_mode = WAL\""}
{"level":30,"time":"2024-10-02T12:06:18.505Z","msg":"MainSQL: migrateDatabase: Migration without cipher change failed"}
{"level":40,"time":"2024-10-02T12:06:18.505Z","msg":"MainSQL: Database log code=26: statement aborts at 2: [PRAGMA user_version] file is not a database"}
{"level":50,"time":"2024-10-02T12:06:18.507Z","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-10-02T12:06:18.507Z","msg":"Failed to get zoom factor {\"name\":\"SqliteError\"}"}
{"level":30,"time":"2024-10-02T12:06:19.244Z","msg":"got fast theme-setting value light"}
{"level":50,"time":"2024-10-02T12:06:20.161Z","msg":"sql.initialize was unsuccessful; returning early"}
{"level":30,"time":"2024-10-02T12:06:20.162Z","msg":"close event {\"readyForShutdown\":false,\"shouldQuit\":false}"}
{"level":30,"time":"2024-10-02T12:06:20.162Z","msg":"maybeRequestCloseConfirmation: Checking to see if close confirmation is needed"}

ramcq · 2024-10-02T12:57:33Z

@hadess This "file is not a database" is consistent with a decryption failure. Maybe just to reduce variables; switch your override to SIGNAL_PASSWORD_STORE=basic as @Altonss suggests, reinstate the config.json backup, and see how you get on? If that doesn't work the db is corrupted, or that's not the key for it.

mbridon · 2024-10-03T07:59:01Z

@ramcq So this worked perfectly for me yesterday. I had to delete the database which I was ok with and Signal launched just fine.

However, today Signal asked me to delete again the database, which is going to be annoying if I can't keep more than a day of history... I have bad memory issue since the flu which attacked my brain, so I need to rely on tools to help me remember things. 😭

And in any case, after I deleted the db again, Signal is now stuck:

$ flatpak run org.signal.Signal 
Debug: Using password store: gnome-libsecret
Debug: Will run signal with the following arguments: --password-store=gnome-libsecret
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 lappy
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/bochecha/.var/app/org.signal.Signal/config/Signal
config/start: Did not find user config file (or it was empty), cache is now empty object
config/get: Successfully read ephemeral config file
making app single instance
LaunchProcess: failed to execvp:
xdg-settings
LaunchProcess: failed to execvp:
xdg-settings
Gtk-Message: 09:50:57.322: Failed to load module "pk-gtk-module"
Gtk-Message: 09:50:57.324: Failed to load module "pk-gtk-module"

It doesn't go any further than that, and doesn't display the window at all after waiting for it for several minutes. 🤦

jntesteves · 2024-10-03T14:32:16Z

@mbridon Are you sure when you run flatpak run org.signal.Signal you're running the version from this PR? The behavior you describe is currently expected on the main branch, because --password-store=gnome-libsecret is still broken there, Signal will fail to start the second time and will require deleting the data.

What responses do you get from the following 2 commands:

secret-tool search application Signal

secret-tool search app_id org.signal.Signal

Edit: Just to be clear, if any of the commands above print a secret key, you have to redact that part before pasting the result anywhere public.

bermeitinger-b · 2024-10-03T17:44:24Z

The behavior you describe is currently expected on the main branch, because --password-store=gnome-libsecret is still broken there, Signal will fail to start the second time and will require deleting the data.

This is only true for Gnome.

flathubbot · 2024-10-04T07:40:43Z

Started test build 151720

flathubbot · 2024-10-04T07:43:06Z

Build 151720 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/134803/org.signal.Signal.flatpakref

bermeitinger-b · 2024-10-04T09:16:24Z

Additional comments:

This PR does not break my currently working setup with gnome-libsecret. So that's good.
Should we use the flatpak-external-data-checker to update this library automatically? (Send a PR, like the main updates)
When this works, we should remove the introduced env var and use the upstreams default choice of password-store. (the --password-store cli switch still would work)

mbridon · 2024-10-04T16:23:03Z

@mbridon Are you sure when you run flatpak run org.signal.Signal you're running the version from this PR? The behavior you describe is currently expected on the main branch, because --password-store=gnome-libsecret is still broken there, Signal will fail to start the second time and will require deleting the data.

What responses do you get from the following 2 commands:
secret-tool search application Signal

secret-tool search app_id org.signal.Signal
Edit: Just to be clear, if any of the commands above print a secret key, you have to redact that part before pasting the result anywhere public.

Hi, here's results for those 2 commands;

$ secret-tool search application Signal
$ secret-tool search app_id org.signal.Signal
[/21]
label = 
secret = [redacted]
created = 2024-09-26 12:26:28
modified = 2024-09-26 12:26:28
schema = org.freedesktop.Secret.Generic
attribute.app_id = org.signal.Signal

salim-b · 2024-10-04T16:31:47Z

@mbridon I think this output means you were not using an org.signal.Signal build with libsecret's file backend disabled, i.e. one that does not include this PR.

mbridon · 2024-10-05T08:09:29Z

@mbridon I think this output means you were not using an org.signal.Signal build with libsecret's file backend disabled, i.e. one that does not include this PR.

I'm now using a version from this PR, as explained in a comment above, I ran this command: flatpak install --user https://dl.flathub.org/build-repo/134803/org.signal.Signal.flatpakref.

The command from another comment above still says the same thing:

secret-tool search app_id org.signal.Signal
[/21]
label = 
secret = [redacted]
created = 2024-09-26 12:26:28
modified = 2024-09-26 12:26:28
schema = org.freedesktop.Secret.Generic
attribute.app_id = org.signal.Signal

So what now? 😕

salim-b · 2024-10-05T12:47:29Z

@mbridon Did you try SIGNAL_PASSWORD_STORE=gnome-libsecret with this build?

To run the Signal test build just once with gnome-libsecret: flatpak run --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal//test

To set the Signal test build to always run with gnome-libsecret: flatpak override --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal

Thanks @hadess for the hint about //test!

hadess · 2024-10-05T21:05:50Z

To run the Signal test build just once with gnome-libsecret: flatpak run --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal

org.signal.Signal//test not org.signal.Signal otherwise it might run the stable release if installed under the user.

bbhtt marked this pull request as draft September 29, 2024 11:08

bbhtt marked this pull request as ready for review September 29, 2024 11:34

bbhtt mentioned this pull request Sep 29, 2024

Signal encryption keyring changed from gnome_libsecret to basic_text #753

Open

bbhtt force-pushed the bbhtt/test-libsecret branch from 117ef20 to 9df1b09 Compare September 29, 2024 13:23

Provide libsecret without crypto backend

2caf105

This uses the Dbus backend instead of the file based ones under Flatpak

bbhtt force-pushed the bbhtt/test-libsecret branch from 9df1b09 to 2caf105 Compare September 29, 2024 15:28

This was referenced Oct 1, 2024

Database Error #723

Open

v7.24.1 is Breaking database signalapp/Signal-Desktop#7029

Open

This was referenced Oct 2, 2024

Only warn if SIGNAL_PASSWORD_STORE is unset. #758

Open

Database Error prevents Signal-Desktop to start signalapp/Signal-Desktop#6970

Open

Merge branch 'master' into bbhtt/test-libsecret

dcda1e4

Build libsecret without gcrypt #756

Are you sure you want to change the base?

Build libsecret without gcrypt #756

Conversation

bbhtt commented Sep 29, 2024 • edited Loading

flathubbot commented Sep 29, 2024

flathubbot commented Sep 29, 2024

minosimo commented Sep 29, 2024

minosimo commented Sep 29, 2024 • edited Loading

salim-b commented Sep 29, 2024 • edited Loading

bermeitinger-b commented Sep 29, 2024

salim-b commented Sep 29, 2024

bbhtt commented Sep 29, 2024 • edited Loading

bbhtt commented Sep 29, 2024

salim-b commented Sep 29, 2024

flathubbot commented Sep 29, 2024

bbhtt commented Sep 29, 2024 • edited Loading

flathubbot commented Sep 29, 2024

flathubbot commented Sep 29, 2024

pm4rcin commented Sep 29, 2024

bbhtt commented Sep 29, 2024

flathubbot commented Sep 29, 2024

salim-b commented Sep 29, 2024

rugk commented Sep 30, 2024 • edited Loading

salim-b commented Sep 30, 2024

ramcq commented Sep 30, 2024

BentHaase commented Oct 1, 2024

bermeitinger-b commented Oct 1, 2024

hadess commented Oct 2, 2024

ramcq commented Oct 2, 2024 • edited Loading

hadess commented Oct 2, 2024

salim-b commented Oct 2, 2024

salim-b commented Oct 2, 2024 • edited Loading

bbhtt commented Oct 2, 2024

hadess commented Oct 2, 2024

ramcq commented Oct 2, 2024

salim-b commented Oct 2, 2024

Altonss commented Oct 2, 2024

ramcq commented Oct 2, 2024

Altonss commented Oct 2, 2024

hadess commented Oct 2, 2024

ramcq commented Oct 2, 2024

mbridon commented Oct 3, 2024

jntesteves commented Oct 3, 2024 • edited Loading

bermeitinger-b commented Oct 3, 2024

flathubbot commented Oct 4, 2024

flathubbot commented Oct 4, 2024

bermeitinger-b commented Oct 4, 2024

mbridon commented Oct 4, 2024

salim-b commented Oct 4, 2024 • edited Loading

mbridon commented Oct 5, 2024

salim-b commented Oct 5, 2024 • edited Loading

hadess commented Oct 5, 2024

bbhtt commented Sep 29, 2024 •

edited

Loading

minosimo commented Sep 29, 2024 •

edited

Loading

salim-b commented Sep 29, 2024 •

edited

Loading

bbhtt commented Sep 29, 2024 •

edited

Loading

bbhtt commented Sep 29, 2024 •

edited

Loading

rugk commented Sep 30, 2024 •

edited

Loading

ramcq commented Oct 2, 2024 •

edited

Loading

salim-b commented Oct 2, 2024 •

edited

Loading

jntesteves commented Oct 3, 2024 •

edited

Loading

salim-b commented Oct 4, 2024 •

edited

Loading

salim-b commented Oct 5, 2024 •

edited

Loading