Decryption Failed happening every week ish. What's happening

[msmafra]

Did the requirements change for it to work?
I'm on Fedora Workstation 41 and it starts happening on both Gnome and Hyprland out of nowhere after a while.

[yngve]

@msmafra See https://help.vivaldi.com/desktop/troubleshoot/decryption-failed-risk-of-data-loss-error-dialog-on-startup/

Are you switching between accounts (or machines) opening the same profile?

[DoctorG]

@msmafra Looks like your Vivaldi browser profile was not opened on the Linux distribution or Linux user where you stored it. The Vivaldi profile uses encryption bound to the Linux user where it was created.

Did you clean Linux user data weekly with tool or cron job?
Did you copy/share your Linux /home/$USER/ data between different Linux distributions?
Did you copy/share your Linux /home/$USER/.config/vivaldi/ and /home/$USER/.cache/vivaldi/ data between different Linux distributions?

[msmafra]

@yngve said in Decryption Failed happening every week ish. What's happening:

Are you switching between accounts (or machines) opening the same profile?

No. Same machine and same Linux user account. Was working yesterday. Vivaldi is my default browser. I don't even use sync on my phone.

[msmafra]

@DoctorG said in Decryption Failed happening every week ish. What's happening:

@msmafra Looks like your Vivaldi browser profile was not opened on the Linux distribution or Linux user where you stored it. The Vivaldi profile uses encryption bound to the Linux user where it was created.

Untouched environment. Simply, worked yesterday and didn't today.

Did you clean Linux user data weekly with tool or cron job?

I see no reason to do that. No, I did not do that.

Did you copy/share your Linux /home/$USER/ data between different Linux
distributions?

No, I didn't. I only use my Vivaldi account on my main system with Fedora Workstation.

Did you copy/share your Linux /home/$USER/.config/vivaldi/ and /home/$USER/.cache/vivaldi/ data between different Linux distributions?

No.

It happened the when I copied my data back from my back after a fresh install weeks ago. It wasn't the behaviour on previous versions, I used to copy my entire .config/.cache etc folders from my backups and it wouldn't cause problems . I logged back in on all my accounts, since then nothing like that again: no new installation, no fresh system install, no copy to another distribution, not copied to another user/login,.

[DoctorG]

@msmafra I do not know more, i guess it could be a problem with the secret in the Linux user's keyring which was not the same as from time of backup.

[vivaldifilip]

You seem to mention switching desktop environments - notably Gnome and Hyprland. This may be the issue, as there is currently no standard for keystores, so vivaldi uses the keystore supplied by the desktop environment (there is an autodetection in place using XDG_CURRENT_DESKTOP variable).

When the keystore differs between the two DEs you are using, you will get this warning to prevent you from losing data (in case of hyprland, the default would be without keystore - equivalent of '--password-store=basic', whereas gnome would be running with the equivalent of '--password-store=gnome-libsecret' switch).

In case you are just using Gnome and Hyprland, you might be in luck, as it's possible to to use gnome keyring in hyprland.

Try using '--password-store=gnome-libsecret' switch when running vivaldi in Hyprland - when unsure if that worked, you can always look into console output - search for :

Password storage detected desktop environment: GNOME_LIBSECRET

when running vivaldi via:

vivaldi --password-store=gnome-libsecret --enable-logging=stderr

On my setup, this also spawns gnome-libsecret, as needed.

This is all a bit confusing (thanks to the fractured nature of linux desktop environments), but the dialog is there to inform you about the situation and protect the profile from damage.

Edit: As was mentioned further down the line, the gnome password store is now using gnome-libsecret switch, so I changed this to better align with the new implementation (was gnome-keyring before).

[edwardp]

@DoctorG I saw this occur (Vivaldi profile prompt) when I installed a second desktop environment (Xfce) on Linux, alongside KDE. Xfce uses the GNOME keyring, where KDE uses its own.

When I attempted to open the default profile, it didn't work with Xfce, but still worked perfectly with KDE.

[DoctorG]

@edwardp Yes, if running XFCE on same profile that happens.

[msmafra]

@vivaldifilip
I've been using vivaldi --password-store=gnome-libsecret --ozone-platform=wayland for a while with a keybind to launch it on Hyprland, since it doesn't work with {electron,chromium}-flags.conf (or similar) file.
. It out of nowhere started doing it. I did a fresh install fo my system for now with no configuration changes whatsoever as it started with no configuration changes whatsoever.
Using gnome-keyring doesn't work for me probably some changes on Gnome 47 GCR etc that I don't know how to account for.

[vivaldifilip]

@msmafra Interesting. Does anything suspicious show up when running from console (with the --enable-logging=stderr, or even with '--vmodule=*/os_crypt/*=1'?

[becm]

@msmafra libsecret should try to access a respective org.fredesktop.secret DBus endpoint.

It could be possible there are competing providers and from time to time a different one is picked due to startup or resolution inconsistencies.
This will lead to issues due inconsistent entries in their respective data stores.

[msmafra]

@vivaldifilip I test it.

[markaslaw]

What I have found is that I lose my saved passwords when I get this message. When I do, the solution is to log out, not roboot but log out and log back in and this seems to resolve the issue. There is no rhyme or reson as to why this should be, but it seems to. File this under "undocumented feature," aka "BUG."

[msmafra]

@vivaldifilip as it is working still (and hopefuly it keeps working) I tested via terminal adding those 2 parameters and also with them but without the --password-store=gnome-libsecret too.

❯ vivaldi --ozone-platform=wayland -enable-logging=stderr '--vmodule=*/os_crypt/*=1'
[23151:23151:1121/093449.624117:WARNING:chrome_main_delegate.cc(773)] This is Chrome version 130.0.6723.129 (not a warning)
[23151:23151:1121/093449.832841:WARNING:wayland_object.cc(178)] Binding to wl_seat version 8 but version 9 is available.
[23151:23151:1121/093449.833127:WARNING:wayland_object.cc(178)] Binding to zwp_pointer_gestures_v1 version 1 but version 3 is available.
[23151:23151:1121/093449.833435:WARNING:wayland_object.cc(178)] Binding to zwp_linux_dmabuf_v1 version 3 but version 5 is available.
[23151:23151:1121/093450.167332:VERBOSE1:key_storage_util_linux.cc(54)] Password storage detected desktop environment: (unknown)
[23151:23151:1121/093450.167347:VERBOSE1:key_storage_linux.cc(141)] Selected backend for OSCrypt: BASIC_TEXT
[23151:23151:1121/093450.167352:VERBOSE1:key_storage_linux.cc(160)] OSCrypt did not initialize a backend.
[23151:23151:1121/093450.170603:INFO:search_engines_manager.cc(556)] search_egines.json sucessfully updated.
[23151:23151:1121/093450.188037:WARNING:wayland_surface.cc(197)] Server doesn't support zcr_alpha_compositing_v1.
[23151:23151:1121/093450.188049:WARNING:wayland_surface.cc(212)] Server doesn't support overlay_prioritizer.
[23151:23151:1121/093450.188052:WARNING:wayland_surface.cc(228)] Server doesn't support surface_augmenter.
[23151:23151:1121/093450.188055:WARNING:wayland_surface.cc(243)] Server doesn't support wp_content_type_v1
[23151:23151:1121/093450.188057:WARNING:wayland_surface.cc(262)] Server doesn't support zcr_color_management_surface.
[23151:23151:1121/093450.188788:WARNING:account_consistency_mode_manager.cc(79)] Desktop Identity Consistency cannot be enabled as no OAuth client ID and client secret have been configured.
[23217:1:1121/093450.193693:WARNING:runtime_features.cc(635)] Topics cannot be enabled in this configuration. Use --enable-features=BrowsingTopics in addition.
[23218:1:1121/093450.195106:WARNING:runtime_features.cc(635)] Topics cannot be enabled in this configuration. Use --enable-features=BrowsingTopics in addition.
[23151:23151:1121/093450.232765:WARNING:org_gnome_mutter_idle_monitor.cc(95)] org.gnome.Mutter.IdleMonitor D-Bus service does not exist
[23151:23151:1121/093450.238204:ERROR:object_proxy.cc
(576)] Failed to call method: org.freedesktop.ScreenSaver.GetActive: object_path= /org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.UnknownMethod: Unknown method GetActive or interface org.freedesktop.ScreenSaver.
[23151:23151:1121/093450.238824:WARNING:idle_linux.cc(110)] None of the known D-Bus ScreenSaver services could be used.
[23199:23199:1121/093450.437242:WARNING:vaapi_wrapper.cc(1534)] Skipping nVidia device named: nvidia-drm
[23151:23151:1121/093450.451076:INFO:direct_match_service.cc(245)] Downloaded Direct Match list from server.
[23199:23199:1121/093450.478523:WARNING:viz_main_impl.cc(85)] VizNullHypothesis is disabled (not a warning)
[23151:23151:1121/093453.149490:VERBOSE1:os_crypt_linux.cc(213)] Decryption failed: could not get the key
[23151:23151:1121/093453.149526:WARNING:vivaldi_keystore_checker.cc(79)] KeystoreChecker: Decryption of the canary failed. Keystore may have changed!
[23151:23151:1121/093453.149539:ERROR:vivaldi_keystore_checker.cc(163)] KeystoreChecker: Profile Profile 8: Encryted keystore changed or is now unavailable. This may result in lost cookies and other problems.

[becm]

@msmafra alt least Hyprland (I assume?) is not in the auto-detection list and will fall back to BASIC_TEXT.

So selecting a specific OSCrypt implementation is likely required for consistent behavior.
You can enforce --password-store=basic for most consistent (but least secure) mode.
Having to set up your Profile with that secret store a last time, of course.

Explicitly selecting GNOME_LIBSECRET can still have two disparities:

• different implementations (as mentioned earlier) or
• failing to auto-start a not yet running provider

@markaslaw this is caused by deep magic of Chromium interacting with various inconsistent system setups.
Showing a warning in case of problems might be the only viable mitigation.
If the system can guarantee a consistent view of it's secret storage implementations, you never see this error.

[becm]

@vivaldifilip shouldn't the removal of gnome-keyring support already have hit Vivaldi a while ago?

[vivaldifilip]

@becm You're right, I gave an outdated advise there with gnome-keyring - should've been gnome-libsecret

@msmafra - becm summed it up nicely - parts of the profile are encrypted with a key derived from data stored in the password store that is platform specific. The issues usually arise when people switch desktop environments on linux. Forcing one password store implementation via the command line switch can be used to influence what chromium chooses, but you still need to provide a stable environment in case you want to use that choice.

The log indicates that by default in that situation you would run basic password store, which does not use any system to store the encryption key securely. It's still usable, but less secure. When you switch to gnome, vivaldi will detect that and try to run with gnome-libsecret instead. This is where the disparity probably comes from.

The log further states that in the past the situation was different - so the detection works as expected.

[markaslaw]

@becm so back in the "good old days of MS DOS" I would simply reformat my hard drive and that would be the end of it. Everyone was happy and it really wasn't that big a deal back then because a REALLY big hard drive was maybe 40 MB and programmers kept things small and tight. Not so today. What's the solution? Do I reinstall Kubuntu and reinstall everything? Or do I just live with it?

[becm]

@markaslaw flaky behavior is mostly observable due to

• multiple systems accessing the same profile → inconsistent secrets
• auto-login (or resume) without password prompt → inaccessible secret store

As already mentioned, if the system can not be coerced to provide a stable secret store behavior,
a possible option is to trigger the use of an insecure hardcoded (publicly known) encryption key.

If you add the respective command line setting to a modified Vivaldi config in
~/.local/share/applications/vivaldi-stable.desktop
you will have consistent behavior at the price of less security.

You will have to

• export your passwords beforehand
• create the modified Vivaldi launch configuration
• remove the Login Data file in the profile folder and
• re-import your passwords after the switch to the basic encryption scheme.