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

Bug #1763829 reported by Olivier Tilloy on 2018-04-13
This bug affects 4 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Olivier Tilloy

Bug Description

(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) wrote :

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

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Olivier Tilloy (osomon)
Olivier Tilloy (osomon) wrote :

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) wrote :

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) wrote :

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) wrote :

Full wrapper:

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
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) wrote :

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) wrote :

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) wrote :

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

Olivier Tilloy (osomon) on 2018-04-16
Changed in chromium-browser (Ubuntu):
status: Confirmed → In Progress
Olivier Tilloy (osomon) wrote :

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) wrote :

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

Olivier Tilloy (osomon) wrote :

Thanks for testing!

Changed in chromium-browser (Ubuntu):
status: In Progress → Fix Committed
Olivier Tilloy (osomon) wrote :

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) wrote :

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.


Olivier Tilloy (osomon) wrote :

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

Changed in chromium-browser (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers