Build libsecret without gcrypt

[bbhtt]

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]

Started test build 150490

[flathubbot]

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]

On Fedora 40 this works.

[minosimo]

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]

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]

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]

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]

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]

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]

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]

Started test build 150509

[bbhtt]

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]

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

[flathubbot]

Started test build 150532

[pm4rcin]

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]

No that's unrelated.

[flathubbot]

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]

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]

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]

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]

@bbhtt This works here. Thanks v. much!

[BentHaase]

@bbhtt Works for me, F40 👍

[mbridon]

@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]

@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]

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.

[mbridon]

I've tried Signal straight from Flathub, as well as Signal from this PR, and both give me the same thing: wipe my db everythime I start the app. 😭

[bermeitinger-b]

I think you have to delete your old database and configuration prior to testing this PR. It cannot just magically recover a lost encryption key.

[pm4rcin]

I think I've figured out what's going on with all that crap or at least I have a bit of information. I'll try to provide more details later (evening if I have enough time) but for now if anyone can check how many entries Signal creates in cleaned secret storage? And does Signal create an entry with the name "Chrome Safe Storage Control"?

[mbridon]

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

Well, I still have the same output, but today when I started Signal it just worked without needing to do anything. 🤷

As for your other other questions, how can I do that?

[mbridon]

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

So, since yesterday, Signal actually works and I don't get the prompt to delete the database any more.

However, I still have the same output for this command:

$ 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

[bermeitinger-b]

Nothing changed since yesterday but good for you.

I don't know why this entry was created and how, but Signal will not remove any password from your keyring. That's a good thing!
If you want, you could remove it after a prior backup, of course.

[mbridon]

Nothing changed since yesterday but good for you.

I don't know why this entry was created and how, but Signal will not remove any password from your keyring. That's a good thing! If you want, you could remove it after a prior backup, of course.

Remove what?

[bermeitinger-b]

The quoted entry in your keyring.

[mbridon]

The quoted entry in your keyring.

And how do I do that? 😕

[minosimo]

There is no reason to delete that entry. The keyring entry that has no label and the attribute app_id org.signal.Signal is written by the bad update. This is the one that we could potentially decrypt to restore people's message history. libsecret serializes and I think also encrypts those entries. I haven't found a cli utility that reads these items, so I tried going through the libsecret source to find an easy way to deserialize them, but it's rather difficult to pick through.

The correct keyring item, as written by the build in this PR, has the label Chromium Safe Storage and the attribute application Signal

Chrome Safe Storage Control literally contains a link to a description of why it exists, and is unrelated to this PR or the previous updates.

[pm4rcin]

Chrome Safe Storage Control literally contains a link to a description of why it exists, and is unrelated to this PR or the previous updates.

Then tell me why Signal complains that database is corrupted and if I grant it access it decrypts successfully? Never mind I've got lost and after re-reading this PR and other issues mentioned I was wrong. Sorry for the noise.

[bermeitinger-b]

Where do you "grant it access"?

You either use basic as password store, then Signal encrypts the database and stores the key in the config.json or you use gnome-libsecret and Signal stores the key in your host's keyring: that's where you can see the entry with secret-tool lookup application Signal.

If the latter is working for you, then thank you for testing this PR. If not, please provide additional logs with your environment information.

[RayJW]

I had the corrupted DB issue initially and restored fine with a backup. I can also confirm that the version from this PR has fixed the issue on my devices! Thanks for all the work :)

[AntonOellerer]

Hey,
For me, running fedora 40, it also fixed the issue, thank you!

[flathubbot]

Started test build 153081

[flathubbot]

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

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

[flathubbot]

Started test build 154478

[flathubbot]

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

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

[mbridon]

So, Signal now works for me, but it takes insanely long to start, like, I started Signal about an hour ago and it's still not up with the window visible yet. 🤯

Running it in the command line I see this:

$ 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/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: 10:13:01.677: Failed to load module "pk-gtk-module"
Gtk-Message: 10:13:01.679: Failed to load module "pk-gtk-module"

And that's pretty much it, it doesn't go any further than that, but sometimes I eventually see the window at some point. 😕

[MannyC]

Is there an intention for this to be merged or how is this going to go?

[flathubbot]

Started test build 155074

[flathubbot]

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

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

[mbridon]

So, Signal now works for me, but it takes insanely long to start, like, I started Signal about an hour ago and it's still not up with the window visible yet. 🤯

Running it in the command line I see this:

$ 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/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: 10:13:01.677: Failed to load module "pk-gtk-module"
Gtk-Message: 10:13:01.679: Failed to load module "pk-gtk-module"

And that's pretty much it, it doesn't go any further than that, but sometimes I eventually see the window at some point. 😕

So I left it hanging for several hours and it wouldn't do anything, then hit ctrl+c to kill it and restarted the same command, and now the window opened just fine. 🤷