[snap] chromium won't start after logging in to google account

[Olivier Tilloy]

(issue initially reported on the forum: https://forum.snapcraft.io/t/call-for-testing-chromium-65-0-3325-146/4390/20)

$ snap info core chromium | egrep "name|installed"
name: core
installed: 16-2.32.3 (4407) 90MB core
name: chromium
installed: 65.0.3325.181 (274) 144MB -

Steps to reproduce:
1) Install the chromium snap: snap install chromium
2) Launch it: /snap/bin/chromium
3) Click the account button on the right side of the tabs bar, and log into a google account
4) Close the browser window
5) Launch chromium again

Expected result: chromium launches, a window is shown and the user is logged into their google account

Current result: the executable seemingly hangs, no window is shown

[Olivier Tilloy (osomon)]

The following verbose log suggests that libsecret is missing from the snap:

[8021:8236:0413/194753.217679:VERBOSE1:key_storage_util_linux.cc(53)] Password storage detected desktop environment: GNOME
[8021:8236:0413/194753.218064:VERBOSE1:libsecret_util_linux.cc(101)] Could not load libsecret-1.so.0: libsecret-1.so.0: cannot open shared object file: No such file or directory

I tested rebuilding the snap with libsecret-1-0 in the stage packages, and the message went away but still no window.
However after connecting the password-manager-service interface, the issue seemed to be resolved:

    snap connect chromium:password-manager-service

[Olivier Tilloy (osomon)]

In chromium, in function os_crypt::SelectBackend()¹, when GNOME is detected, the backend is SelectedLinuxBackend::GNOME_ANY, which is documented as "GNOME_KEYRING or GNOME_LIBSECRET, whichever is available". This piece of code doesn't seem to automatically fall back to the basic (unencrypted) password store, like the regular login/password storage functionality does.

This can be overridden on the command line though, with "--password-store=basic" (and thus doesn't require the connection of the password-manager-service interface).

¹ https://cs.chromium.org/chromium/src/components/os_crypt/key_storage_util_linux.cc?sq=package:chromium&l=30

[Olivier Tilloy (osomon)]

I wonder whether, as a workaround, the snap wrapper that launches chromium could detect whether the password-manager-service interface is connected, and if not add the --password-store=basic command-line option.

[Olivier Tilloy (osomon)]

Calling the following in the wrapper and checking for the return code should do the trick:

dbus-send --session --dest=org.freedesktop.secrets /org/freedesktop/secrets --print-reply org.freedesktop.DBus.Properties.GetAll string:'org.freedesktop.Secret.Service'

[Olivier Tilloy (osomon)]

Full wrapper:

#!/bin/sh
PASSWORD_STORE=gnome
dbus-send --session --dest=org.freedesktop.secrets /org/freedesktop/secrets --print-reply org.freedesktop.DBus.Properties.GetAll string:'org.freedesktop.Secret.Service' >/dev/null 2>&1
if [ "$?" -ne "0" ]; then
  PASSWORD_STORE=basic
fi
exec "$SNAP/usr/lib/chromium-browser/chromium-browser" --no-default-browser-check --no-first-run --password-store=$PASSWORD_STORE "$@"

This would require some testing on other desktop environments, e.g. KDE.

[Jonas (jonny-boy)]

Is the chromium snap in the stable branch already containing the libsecret-1.so.0?
Would it be possible to push the snap with the libsecret-1.so.0 and the wrapper in the candidate channel so that the users would be able to test it?

[Olivier Tilloy (osomon)]

I have pushed both fixes to the git repository, a build is scheduled and as soon as it's done I will publish it to the candidate channel (I will add a comment here when it's ready for testing).

[Olivier Tilloy (osomon)]

Unfortunately bug #1763641 is blocking publication in the store, I'm working with store people to try and resolve this.

[Olivier Tilloy (osomon)]

Revision 277 in the candidate channel (amd64) has the fix, please test with

    snap refresh chromium --candidate

and add your feedback here. Thanks!

(note: a glitch in the store means publication has to be manually approved for now, so builds for the other supported architectures will be following soon)

[Jonas (jonny-boy)]

For me, chromium starts now as intended. Thanks for the fix.

[Olivier Tilloy (osomon)]

Thanks for testing!

[Olivier Tilloy (osomon)]

For reference, the following commits fix the issue:

https://git.launchpad.net/~chromium-team/chromium-browser/+git/snappy-packaging/commit/?id=5f40c7e269a6990b68669229cf4b7db2c41096bc

https://git.launchpad.net/~chromium-team/chromium-browser/+git/snappy-packaging/commit/?id=794ef552a18646c2ab03121c695d36ee0791de12

[Olivier Tilloy (osomon)]

The fix is in the candidate channel for all supported architectures now.
I'll leave it there for a couple of days to give people an opportunity to test and report, after which I will promote to the stable channel in no issue is raised.

[Ruben Suarez Alvarez (rubensa)]

Ubuntu 18.04 clean install.

Installed chromium snap from stable channel and found the problem (browser worked till I entered my google account and saved password on keyring).

Fond this bug (from https://forum.snapcraft.io/t/call-for-testing-chromium-65-0-3325-146/4390/21 ), changed to candidate and the problem is gone. Now chromium starts without problem.

Thanks!

[Olivier Tilloy (osomon)]

This is now in the stable channel. Thanks for the feedback!