Signal encryption keyring changed from gnome_libsecret to basic_text #753

RelicCornhusk · 2024-09-27T22:42:48Z

For some reason, despite not having made any major updates on my OS (Fedora Workstation 40), I now get this message when trying to open Signal:

Database startup error:

SafeStorageBackendChangeError: Detected change in safeStorage backend, can't decrypt DB key (previous: gnome_libsecret, current: basic_text)
    at getSQLKey ([REDACTED]/app/main.js:1256:11)
    at initializeSQL ([REDACTED]/app/main.js:1317:11)
    at App.<anonymous> ([REDACTED]/app/main.js:1538:20)

App Version: 7.24.1
OS: linux

Any idea why this is happening? I've tried opening signal through the terminal with --password-store=gnome-libsecret and --password-store=basic-text. Passing gnome-libsecret as the argument for the command gives me a similar error, but it gives me the option of deleting the database and restarting signal, which I don't want to have to resort to.

The text was updated successfully, but these errors were encountered:

Maners · 2024-09-27T23:02:38Z

Same just started happening for me, also on Fedora 40

liamreoch · 2024-09-28T05:12:59Z

Can confirm, I updated and got this error.

Running from terminal with that flag then leads this this:

Workaround / fix:

#752 (comment)

Open Flatseal, navigate to Signal, scroll down to "session bus", remove "org.freedesktop.secrets".

Close, then reopen. You will need to relink your device, but it should now work.

bermeitinger-b · 2024-09-28T06:11:50Z

Use flatseal to set the env var SIGNAL_PASSWORD_STORE to gnome-libsecret

bellegarde-c · 2024-09-28T12:41:18Z

@bermeitinger-b Not working here, every startup Signal tells me DB is broken.

RelicCornhusk · 2024-09-28T13:09:44Z

Use flatseal to set the env var SIGNAL_PASSWORD_STORE to gnome-libsecret

I can do that and delete my database, but I'm trying to find a way of not needing to delete my database.

DeltaLima · 2024-09-28T13:55:49Z

Having the same issue. Debian stable bookworm here with flatpak 1.14.10 from debian repo.
I started the Signal flatpak as told with the argument --password-store="gnome-libsecret" and it worked fine for me. But to keep it working, I have to run Signal everytime with this argument.

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

there was no need to delete anything, just worked again.

A short grep in signals flatpak directory ~/.var/app/org.signal.Signal/ revealed that "gnome_libsecret" is already set in the config file, but seem to be ignored

$ grep -r "gnome_libsecret" *
config/Signal/config.json:  "safeStorageBackend": "gnome_libsecret"

salim-b · 2024-09-28T14:11:09Z

But to keep it working, I have to run Signal everytime with this argument.

To set it permanently for your user, set SIGNAL_PASSWORD_STORE via Flatseal or flatpak override on the terminal:

flatpak override org.signal.Signal --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret

minosimo · 2024-09-28T17:44:09Z

I have tried to assemble troubleshooting instructions in one place here: https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222#p-251892-database-error-keyring-backend-has-changed-5

If anyone needs help, please ask in that thread rather than on github.

Maners · 2024-09-28T18:24:00Z

I have tried to assemble troubleshooting instructions in one place here: https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222#p-251892-database-error-keyring-backend-has-changed-5

If anyone needs help, please ask in that thread rather than on github.

The tutoral instructs to use:

secret-tool search application Signal

which did not return anything to me. However, browsing with Seahorse I have found an entry that had no label at all but had app_id attribute set to org.signal.Signal.
Running:

secret-tool search app_id org.signal.Signal

revealed that the entry was created on Sept 26th 2024 so it's not some old leftover. How can I make signal use this one and try to recover using it? My config.json has encrypted password stored and I don't have backup of it, so this option won't work.

minosimo · 2024-09-28T18:45:24Z

I have that entry in my keystore as well. I'm not sure where it came from.

I can only get Signal to launch with gnome-libsecret when the keyring entry is in a Chromium Safe Storage entry with the application set to Signal. I am generating the entry with a script in Electron Fiddle:

const { app, safeStorage } = require('electron');
const { join } = require('node:path');
const { readFileSync, writeFileSync } = require('node:fs');

const folder = '/home/simon/.var/app/org.signal.Signal/config/Signal';
app.setPath('userData', folder);
app.setName('Signal');

app.on('ready', () => {
  const configPath = join(folder, 'config.json');

  const json = readFileSync(configPath, 'utf8');
  // Save backup
  writeFileSync(join(folder, 'config.json.bak'), json);

  const config = JSON.parse(json);
  if (!config.key) {
    console.error('Decrypted key not found in config.json');
    app.quit(1);
    return;
  }

  
  const key = config.key;
  const encrypted = safeStorage.encryptString(key).toString('hex');

  console.log(encrypted)

  const newConfig = {
    ...config,
    encryptedKey: encrypted,
    key: undefined,
  };
  const newJson = JSON.stringify(newConfig, null, 2);
  writeFileSync(configPath, newJson);

  console.log('Success');
  app.quit();
})

mamama1 · 2024-09-28T23:56:02Z

had to set SIGNAL_PASSWORD_STORE=basic and restore a config.json backup with the unencrypted key. if i leave SIGNAL_PASSWORD_STORE=gmome-libsecret, it encrypts the key at start in the config.json but doesn't put it into the system keyring.
Fedora 40 Gnome.

what a royal mess for people without a backup of a supposed to be stateless application

emdnaia · 2024-09-29T00:42:21Z

But to keep it working, I have to run Signal everytime with this argument.

To set it permanently for your user, set Environment > Variables : SIGNAL_PASSWORD_STORE=gnome-libsecret via Flatseal or flatpak override on the terminal:
flatpak override org.signal.Signal --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret

fastest solution

minosimo · 2024-09-29T07:51:41Z

I have tried to assemble troubleshooting instructions in one place here: https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222#p-251892-database-error-keyring-backend-has-changed-5
If anyone needs help, please ask in that thread rather than on github.

The tutoral instructs to use:

secret-tool search application Signal

which did not return anything to me. However, browsing with Seahorse I have found an entry that had no label at all but had app_id attribute set to org.signal.Signal. Running:

secret-tool search app_id org.signal.Signal

revealed that the entry was created on Sept 26th 2024 so it's not some old leftover. How can I make signal use this one and try to recover using it? My config.json has encrypted password stored and I don't have backup of it, so this option won't work.

On a Debian install from the .deb, the key written is called "Chromium Safe Storage" and the attribute is application: Signal, so that's probably the correct key.

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

config.json backup with the unencrypted key. if i leave SIGNAL_PASSWORD_STORE=gmome-libsecret, it encrypts the key at start in the config.json but doesn't put it into the system keyring.

Try testing basic -> gnome_libsecret migration with this PR #756 It should work.

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.

RelicCornhusk · 2024-09-29T14:14:56Z

config.json backup with the unencrypted key. if i leave SIGNAL_PASSWORD_STORE=gmome-libsecret, it encrypts the key at start in the config.json but doesn't put it into the system keyring.

Try testing basic -> gnome_libsecret migration with this PR #756 It should work.

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.

I just tested the PR build and it still won't allow me to get back to my old database despite switching to gnome-libsecret, it prompts me to delete it and restart the application. Is that expected? Should I just do that or is there a chance that there will be a fix that will allow me to go back to my messages/media?

distbit0 · 2024-09-29T23:23:49Z

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.

SoLoR1 · 2024-09-30T11:38:46Z

had to set SIGNAL_PASSWORD_STORE=basic and restore a config.json backup with the unencrypted key. if i leave SIGNAL_PASSWORD_STORE=gmome-libsecret, it encrypts the key at start in the config.json but doesn't put it into the system keyring. Fedora 40 Gnome.

what a royal mess for people without a backup of a supposed to be stateless application

I had same issue on Linux Mint 22, luckily i could restore config.json from daily timeshift backup and switch back to basic password store.

hotrooibos · 2024-09-30T15:00:43Z

Fedora 40. Got this error this morning. Tried the above solutions (flatseal, flatpak override...), but nothing works. I get the following "A database error occurred".
.

Altonss · 2024-09-30T15:06:12Z

Fedora 40. Got this error this morning. Tried the above solutions (flatseal, flatpak override...), but nothing works. I get the following "A database error occurred". .

@hotrooibos you probably are facing this issue #723. You can look at these instructions to try and fix the problem: https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222#p-251892-database-error-a-database-error-has-occurred-6 .

hotrooibos · 2024-09-30T16:30:05Z

@hotrooibos you probably are facing this issue #723.

I only get this once I change the SIGNAL_PASSWORD_STORE variable (either with the above command line, or through flatseal) to gnome-libsecret. If I revert it to basic, I'm back with the current issue. Since I've never installed a non-flatpak version of Signal, I guess my local data is now lost.

Altonss · 2024-09-30T17:22:05Z

I only get this once I change the SIGNAL_PASSWORD_STORE variable (either with the above command line, or through flatseal) to gnome-libsecret. If I revert it to basic, I'm back with the current issue. Since I've never installed a non-flatpak version of Signal, I guess my local data is now lost.

The default has been set to basic, because of issues with gnome-libsecret. You need to leave it on basic for now, and if you have a backup of the Signal config previous to the current bug, you will be able to recover the data like explained in the recovery guide I linked to.

theredsnare · 2024-09-30T18:28:16Z

Use flatseal to set the env var SIGNAL_PASSWORD_STORE to gnome-libsecret

This seemed to solve the problem for me, although I get an alert next to the value suggesting something is wrong.

bermeitinger-b · 2024-09-30T18:29:59Z

This yellow exclamation mark tells you that this value was changed from the default.

theredsnare · 2024-09-30T21:27:09Z

This yellow exclamation mark tells you that this value was changed from the default.

Thank you for the solution and the lesson!

swalter972 · 2024-10-01T13:01:48Z

Nothing worked for me, don't have time to dig for this problem for now, any short answer (flatseal didnt work on latest mint) with resteing also ? Thanks

bermeitinger-b · 2024-10-01T13:42:15Z

Remove your config, and start with a new database.

swalter972 · 2024-10-01T15:15:10Z

I don't want to remove my bueatiful Mint configuration, nore my grpahic card ^^
HOw do I delete the database and restart from scratch ? (nope uninstall and reinstall didnt do the job, nor the flatseal solution,)

salim-b · 2024-10-01T15:19:32Z

HOw do I delete the database and restart from scratch ? (nope uninstall and reinstall didnt do the job, nor the flatseal solution,)

Either via flatpak uninstall --delete-data org.signal.Signal or via rm -r ~/.var/app/org.signal.Signal (supposed you're using the default user-config path). This applies to any Flatpak app.

TheRoarkster · 2024-10-01T23:53:54Z

Same issue on Manjaro. Can someone who knows please confirm this is a bug and not a a feature? Is it something that will be addressed in an update -- or is the "solution" for users to manually enter flatpak override org.signal.Signal --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret in a terminal?

illwieckz · 2024-10-06T17:57:50Z

I have tried to assemble troubleshooting instructions in one place here: https://community.signalusers.org/t/warning-do-not-update-from-flathub-database-error/63222#p-251892-database-error-keyring-backend-has-changed-5
If anyone needs help, please ask in that thread rather than on github.

The tutoral instructs to use:

secret-tool search application Signal

which did not return anything to me. However, browsing with Seahorse I have found an entry that had no label at all but had app_id attribute set to org.signal.Signal. Running:

secret-tool search app_id org.signal.Signal

revealed that the entry was created on Sept 26th 2024 so it's not some old leftover. How can I make signal use this one and try to recover using it? My config.json has encrypted password stored and I don't have backup of it, so this option won't work.

I'm in the exact same situation as this one regarding to not having a Signal application entry but having an org.signal.Signal app_id entry. On my end this app_id entry is from 2024-09-27, so very recent, around the days Signal started to work for me.

No suggested solution makes it possible to run Signal on my end (changing the password store to basic asks me to delete my data).

Akbar30Bill · 2024-10-07T14:02:38Z

if someone gives me some clue id be happy to fix this issue. this is starting to prevent me from working.

mtimofiiv · 2024-10-08T02:09:59Z

Same here. I've re-created the database now 4 times. I have tried everything in this thread already. I have the env var SIGNAL_PASSWORD_STORE=gnome-libsecret and the config file has the key and "safeStorageBackend": "gnome_libsecret" is set.
My output in terminal matches @olaf-meyer's. I'm on Pop_OS.
I don't care about losing my messages, so happy to test.

Set the password store to basic. https://community.signalusers.org/t/troubleshooting-guide-database-error-after-flatpak-update-from-flathub/63222

This worked to fix the immediate issue, the app now works as it did before. Thanks!

adonig · 2024-10-10T10:42:41Z

My dad had this issue on his laptop a week ago. I sent him the troubleshooting instructions above. I'm not sure whether he tried it yet. Today after doing updates I got the same error on Fedora 40:

I followed the given instructions but the command secret-tool search application Signal returns nothing.

I made a backup of the ~/.var/app/org.signal.Signal, deleted that folder and started Signal with the basic password store.

I had to link the laptop again now all conversations are gone. Yay ... 2024, the year of the Linux desktop! 👏👏👏

If anyone finds a solution to bring back my data using the backup or some other hack, let me know.

mamama1 · 2024-10-10T10:44:33Z

I'm blaming Signal for this.
Do you actually HAVE a backup?

minosimo · 2024-10-10T10:45:50Z

My dad had this issue on his laptop a week ago. I sent him the troubleshooting instructions above. I'm not sure whether he tried it yet. Today after doing updates I got the same error on Fedora 40:

I followed the given instructions but the command secret-tool search application Signal returns nothing.

I made a backup of the ~/.var/app/org.signal.Signal, deleted that folder and started Signal with the basic password store.

I had to link the laptop again now all conversations are gone. Yay ... 2024, the year of the Linux desktop! 👏👏👏

If anyone finds a solution to bring back my data using the backup or some other hack, let me know.

Before resetting Signal, did you try starting with the password store set to gnome-libsecret? It's odd that your install would break this late, please post the output of flatpak info org.signal.Signal

adonig · 2024-10-10T11:00:26Z

Before resetting Signal, did you try starting with the password store set to gnome-libsecret?

I did flatpak run org.signal.Signal --password-store"gnome-libsecret" but it looks like flatpak run doesn't pass the command line args following the app.

I restored the backup now and tried this:

flatpak override --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal && flatpak run org.signal.Signal

Now I get the error message telling me to contact Signal support:

That's probably because there is no key in the keystore, like I confirmed before using secret-tool.

So I probably have to delete the Signal folder and all my messages again to get a working Signal desktop client?

EDIT: Forgot the flatpak info output

$ flatpak info org.signal.Signal

Signal Desktop - Private messenger

          ID: org.signal.Signal
         Ref: app/org.signal.Signal/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 7.24.1
     License: AGPL-3.0-only
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 479.4 MB
     Runtime: org.freedesktop.Platform/x86_64/24.08
         Sdk: org.freedesktop.Sdk/x86_64/24.08

      Commit: 3e5c47a7a1bd648422eb36ac583e58c851391802fe962ccf66c88109e666366b
      Parent: 2d3107e48d9f49cbcc0c1667448b7c3429dab28176daf066b2eb33f79e121c45
     Subject: Use correct desktop file name (#761) (d8bb69c9)
        Date: 2024-10-04 07:41:25 +0000

minosimo · 2024-10-10T11:05:44Z

The update that causes the database to become unreadable hasn't been live for some time. I assume you launched Signal maybe once in the past week, or kept it running for a long time?

Otherwise, yes, if the Signal entry is not in the keyring, and you don't have a config.json with the unencrypted key in it, you will need to start fresh without the conversation history.

adonig · 2024-10-10T11:09:57Z

The update that causes the database to become unreadable hasn't been live for some time. I assume you launched Signal maybe once in the past week, or kept it running for a long time?

I kept it running for like three weeks. Today I updated the kernel and did a reboot and the issue showed up. My dad got the issue last week. I hope he has a Signal entry in his keyring because if I'm going to delete his Signal messages, he's probably never going to do an update on his laptop again.

salim-b · 2024-10-10T11:12:54Z

I'm blaming Signal for this.

You can blame Signal for building their desktop app on Electron.

You can blame Electron for relying on Chromium to render an app's front-end.

And finally, you can blame Chromium for implementing the "wrong" libsecret API – and causing this whole mess. 😉

mamama1 · 2024-10-10T11:12:55Z

for me, i had to set SIGNAL_PASSWORD_STORE to basic and restore my config.json from a point in time where the key was unencrypted. then everything resumed to normal.

mamama1 · 2024-10-10T11:17:21Z

I'm blaming Signal for this.

You can blame Signal for building their desktop app on Electron.

You can blame Electron for relying on Chromium to render an app's front-end.

And finally, you can blame Chromium for implementing the "wrong" libsecret API – and causing this whole mess. 😉

despite the fact that this is free software and we have very little ground to complain or blame at all, i think it would have been in Signal's responsibility to test properly and frequently and work around/handle errors like that. if their framework breaks, it is still them building on it and since no end user has the choise of changing the framework, imho it would've been Signals responsibility to take action accordingly.

imagine if something similar would have happened on windows, let alone android or iOS - Signal would be royally f**** by the sh*tstorm. they're just lucky, that the Linux desktop user base isn't that big.

minosimo · 2024-10-10T11:18:41Z

I kept it running for like three weeks. Today I updated the kernel and did a reboot and the issue showed up. My dad got the issue last week. I hope he has a Signal entry in his keyring because if I'm going to delete his Signal messages, he's probably never going to do an update on his laptop again.

Ask him to run
cat ~/.var/app/org.signal.Signal/config/Signal/config.json
secret-tool search application Signal
secret-tool search app_id org.signal.Signal

That should give you all the info you need to know if he has the bad update or not. If his key is already encrypted but Signal is still running, the key must be floating around somewhere in RAM, but I couldn't tell you how to get at it.

minosimo · 2024-10-10T11:30:52Z

The issue was not with Signal, who tested the update and as far as I know have not caused anything to break. The database issues are only present in the flatpak build (which is managed by volunteers) that got pushed to flathub. Maybe the snap build as well.

salim-b tactfully left out a step. The broken update was merged to master almost immediately, which automatically pushes the update to flathub. There was only a window of about three hours where the change could be tested. The issue was reported just four hours later, but went basically ignored, and the broken commit was not reverted for two days. (edited for accuracy)

This is fundamentally an issue with flathub, where changes can be merged very easily by whoever manages a package. Distro repositories usually have a slightly more involved process. For instance Fedora uses a karma system to determine whether updates can be published to stable or not.

salim-b · 2024-10-10T13:17:45Z

salim-b tactfully left out a step.

Fair. Merging #729 without more testing was a failure in hindsight. I guess the people involved felt some kind of urgency to act due to the accompanying media reports / social media drama.

This is fundamentally an issue with flathub, where changes can be merged very easily by whoever manages a package. Distro repositories usually have a slightly more involved process. For instance Fedora uses a karma system to determine whether updates can be published to stable or not.

Yeah, OTOH official distro packages are almost always horribly out-of-date and Flatpak and Flathub provide the right technology/infrastructure to overcome the Linux desktop app packaging fragmentation.

IMHO, the real solution to the problem here would be Signal Foundation taking over maintainership of this Flatpak.

wrobbins · 2024-10-10T16:03:41Z

I've been monitoring this issue since it happened to me. Regardless of the technicalities I mostly agree with the opinions recently expressed. Potentially losing all messages on a device is not good.

Yay ... 2024, the year of the Linux desktop!

This is the kind of cynical sarcasm I enjoy and would have posted a similar message if I was feeling spicy. This is a bad look for Signal/Linux.

imagine if something similar would have happened on windows, let alone android or iOS - Signal would be royally f****

Yep would have probably lost users

IMHO, the real solution to the problem here would be Signal Foundation taking over maintainership of this Flatpak.
Yes OR

Introduce automated testing to prevent issues like this happening again
Eject from the Flatpak ecosystem and introduce a real Fedora repository with official builds. RPM fusion does not count.

Yes, it's cool that Signal is free. Signal is also free on iOS, MacOS, Windows, and Android. There are also a number of free alternatives that people might go to. It's already hard enough to convince people to switch to Signal.

I recognize maintainers are probably frustrated that it happened and that people are piling on. If there's a postmortem I hope emotions can be left at the door and feedback like this will be considered.

I'm a software developer, what can I do to help? Is it possible for people to donate to directly fund prevention of this in the future like adding tests etc ?

salim-b · 2024-10-10T17:02:43Z

Introduce automated testing to prevent issues like this happening again
I'm a software developer, what can I do to help?

PRs to this Flatpak are welcome AFAICT, so feel free to help out with this! I suppose it is quite a challenge to implement pairing of Signal Desktop with a main Signal app instance (Android/iOS; using some test account) in CI. And way too much to ask of volunteers IMHO.

Eject from the Flatpak ecosystem and introduce a real Fedora repository with official builds. RPM fusion does not count.

That's the exact opposite of a solution to the packaging burden problem (and obviously would only work for Fedora users). See e.g. signalapp/Signal-Desktop#1630, you're not the first person requesting packaging for their favorite distro.

bermeitinger-b · 2024-10-10T19:38:54Z

Please keep this thread about the key storage and probable recovery issues. Or ideas on how to migrate moving forwards.

adonig · 2024-10-10T19:47:23Z

I found a config.json with an encrypted key in my backup. Does this mean I can restore my messages somehow?

{
  "mediaPermissions": true,
  "mediaCameraPermissions": true,
  "encryptedKey": "<REDACTED>",
  "safeStorageBackend": "gnome_libsecret"
}

mamama1 · 2024-10-10T19:59:09Z

I found a config.json with an encrypted key in my backup. Does this mean I can restore my messages somehow?
{
  "mediaPermissions": true,
  "mediaCameraPermissions": true,
  "encryptedKey": "<REDACTED>",
  "safeStorageBackend": "gnome_libsecret"
}

no, you need the unencrypted key version of the file, as i've stated earlier.

heyakyra · 2024-10-17T06:45:50Z

@Maners wrote:

The tutoral instructs to use:

secret-tool search application Signal

which did not return anything to me. However, browsing with Seahorse I have found an entry that had no label at all but had app_id attribute set to org.signal.Signal.

@minosimo wrote:

I have that entry in my keystore as well. I'm not sure where it came from.

I can only get Signal to launch with gnome-libsecret when the keyring entry is in a Chromium Safe Storage entry with the application set to Signal. I am generating the entry with a script in Electron Fiddle

Is there no way to just look at the existing entry without creating a new one? Or just decrypt it to switch back to the normal encryption?

bermeitinger-b · 2024-10-17T08:48:26Z

It is possible, but the surrounding Flatpak framework would not be responsible. It might be possible in Signal's code or any other layer between Signal and Flatpak that interacts with the keyring (Electron, Chromium, etc.). I would not dare introduce logic that checks all keyring entries—imagine the headline: Signal reads all your passwords.

solt87 · 2024-10-20T11:12:01Z

I had to link the laptop again now all conversations are gone. Yay ... 2024, the year of the Linux desktop! 👏👏👏

It has nothing to do with "the (year of the) Linux desktop" (which has been here for 10+ years), and everything to do with "3rd party ~~program repositories~~ appstores". This is what happens when the "bad, baaad" distribution-provided packages and settings are replaced with 3rd-party cr@p. You get misbehaving programs, data loss, tons of "documentation" to read through, conflicting pieces of advice on solving the problem, and pointing the finger at someone else. Yay, alternative program sources! 👏👏👏

bermeitinger-b · 2024-10-20T11:27:34Z

Please stay on topic and leave angry and troll messages to yourself. This is not the right place.

heyakyra · 2024-10-23T01:51:38Z

@bermeitinger-b wrote:

I would not dare introduce logic that checks all keyring entries—imagine the headline: Signal reads all your passwords.

Signal was responsible for creating that entry, right? Why not some logic that only searches for that entry in particular?

Anyways, it's probably not worth the effort but it'd be worthwhile for those stuck in this weird state to have a manual script like @minosimo created above (but to the effect of switching back to basic rather than creating a new keyring entry with the right label)

heyakyra · 2024-10-26T21:50:43Z

I tried to pipe the existing entry password to a new one with the right application attribute, but I get this error:

$  secret-tool lookup app_id org.signal.Signal | secret-tool store --label='Chromium Safe Storage' application Signal
secret-tool: password not valid UTF-8

liamreoch mentioned this issue Sep 28, 2024

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

Open

2 tasks

carpediem29 mentioned this issue Oct 7, 2024

Database Error #723

Open

XenonSup mentioned this issue Oct 21, 2024

Database Error after update to 7.29 #774

Closed

bshephar mentioned this issue Oct 27, 2024

Unable to access the database encryption key #752

Closed

TheRoarkster mentioned this issue Nov 5, 2024

Only-Office Desktop Editors getsolus/packages#4256

Closed

2 tasks

Signal encryption keyring changed from gnome_libsecret to basic_text #753

Signal encryption keyring changed from gnome_libsecret to basic_text #753

Comments

RelicCornhusk commented Sep 27, 2024 • edited Loading

Maners commented Sep 27, 2024

liamreoch commented Sep 28, 2024 • edited Loading

Workaround / fix:

bermeitinger-b commented Sep 28, 2024 • edited Loading

bellegarde-c commented Sep 28, 2024

RelicCornhusk commented Sep 28, 2024

DeltaLima commented Sep 28, 2024

salim-b commented Sep 28, 2024 • edited Loading

minosimo commented Sep 28, 2024

Maners commented Sep 28, 2024

minosimo commented Sep 28, 2024

mamama1 commented Sep 28, 2024 • edited Loading

emdnaia commented Sep 29, 2024 • edited Loading

minosimo commented Sep 29, 2024

bbhtt commented Sep 29, 2024 • edited Loading

RelicCornhusk commented Sep 29, 2024

distbit0 commented Sep 29, 2024

SoLoR1 commented Sep 30, 2024

hotrooibos commented Sep 30, 2024

Altonss commented Sep 30, 2024

hotrooibos commented Sep 30, 2024

Altonss commented Sep 30, 2024

theredsnare commented Sep 30, 2024

bermeitinger-b commented Sep 30, 2024

theredsnare commented Sep 30, 2024

swalter972 commented Oct 1, 2024

bermeitinger-b commented Oct 1, 2024

swalter972 commented Oct 1, 2024

salim-b commented Oct 1, 2024

TheRoarkster commented Oct 1, 2024

illwieckz commented Oct 6, 2024 • edited Loading

Akbar30Bill commented Oct 7, 2024

mtimofiiv commented Oct 8, 2024

adonig commented Oct 10, 2024

mamama1 commented Oct 10, 2024

minosimo commented Oct 10, 2024 • edited Loading

adonig commented Oct 10, 2024 • edited Loading

minosimo commented Oct 10, 2024

adonig commented Oct 10, 2024

salim-b commented Oct 10, 2024

mamama1 commented Oct 10, 2024

mamama1 commented Oct 10, 2024

minosimo commented Oct 10, 2024

minosimo commented Oct 10, 2024 • edited Loading

salim-b commented Oct 10, 2024 • edited Loading

wrobbins commented Oct 10, 2024

salim-b commented Oct 10, 2024

bermeitinger-b commented Oct 10, 2024

adonig commented Oct 10, 2024

mamama1 commented Oct 10, 2024

heyakyra commented Oct 17, 2024

bermeitinger-b commented Oct 17, 2024

solt87 commented Oct 20, 2024

bermeitinger-b commented Oct 20, 2024

heyakyra commented Oct 23, 2024

heyakyra commented Oct 26, 2024

RelicCornhusk commented Sep 27, 2024 •

edited

Loading

liamreoch commented Sep 28, 2024 •

edited

Loading

bermeitinger-b commented Sep 28, 2024 •

edited

Loading

salim-b commented Sep 28, 2024 •

edited

Loading

mamama1 commented Sep 28, 2024 •

edited

Loading

emdnaia commented Sep 29, 2024 •

edited

Loading

bbhtt commented Sep 29, 2024 •

edited

Loading

illwieckz commented Oct 6, 2024 •

edited

Loading

minosimo commented Oct 10, 2024 •

edited

Loading

adonig commented Oct 10, 2024 •

edited

Loading

minosimo commented Oct 10, 2024 •

edited

Loading

salim-b commented Oct 10, 2024 •

edited

Loading