The chromium browser has been available as a deb package for all supported Ubuntu releases and as a snap since version 60, and the time has come to start transitioning away from the debs.
In a first step, the transition will be happening exclusively for Ubuntu 19.10 (Eoan Ermine) users, and once I’m confident it is rock-solid it will be rolled out to stable releases, starting with disco and then the LTSes.
How does that work? The deb packages have been updated in eoan to install the stable snap on upgrade or new install (credit for the original implementation goes to the LXC team). Special care has been taken to not break existing workflows and to make the transition seamless:
when running the snap for the first time, an existing chromium user profile in $HOME/.config/chromium will be imported (provided there is enough disk space)
the chromium-browser and chromedriver executables in /usr/bin/ are wrappers that call into the respective snap executables
chromedriver has been patched so that existing selenium scripts should keep working without modifications
if chromium was the default browser, the chromium-browser wrapper will take care of updating it to the chromium snap
similarly, existing pinned entries in desktop launchers will be updated to point to the snap version (implemented for GNOME Shell and Unity only for now, contributions welcome for other desktop environments)
the apport hook has been updated to include relevant information about the snap package and its dependencies
If you live on the edge and are running Ubuntu 19.10 already, I would appreciate your feedback on this transition. Please share it here, or file bugs with ubuntu-bug chromium-browser.
But why deb is being replaced with snap in the main archive ? I use Pop_os/Ubuntu-Mate and it doesn’t even have snap. How do I continue using/testing chromium deb ? Can you provide a PPA ?
[quote="zippyzebu, post:2, topic:11772]
Well 32bit snap version is crashing for me.
[/quote]
Can you provide details about that crash? Which version of Ubuntu, which channel of the chromium snap, what desktop environment, does it crash right away at startup or are there a specific set of actions/pages that trigger the crash?
[quote="zippyzebu, post:2, topic:11772]
But why deb is being replaced with snap in the main archive ? I use Pop_os/Ubuntu-Mate and it doesn’t even have snap. How do I continue using/testing chromium deb ? Can you provide a PPA ?
[/quote]
Technically, chromium is in universe, not in main (see this documentation). The deb packages won’t disappear, but they are becoming transitional packages that install the snap when installing/upgrading.
I’m not sure about Pop!_OS, but I’m pretty sure Ubuntu Mate supports snaps as first-class citizens.
Once the transition is complete there won’t be a PPA maintained by the Ubuntu desktop team, because one of the goals of this transition is to relieve some of the packaging/maintenance work.
@oSoMoN hi, the deb package source ~/.chromium-browser.init if available in order to pass additional chromium flags on startup without having to modify .desktop launcher. Could chromium snap introduce similar functionality? Of course ~/.chromium-browser.init should be sourced from snap specific home (inside ~/snap) in that case.
fails o my system (Ubuntu 19.04 + KDE session + kwallet) saying that nothing provides org.freedesktop.Secret.Service and chromium fallbacks to plain backend (losing my passwords). When I add --password-store=kwallet to desktop file command it works correctly.
So current approach for backed detection is broken in my case (maybe in general for kwallet). Maybe it’s possible to test also kwallet equivalent of that command however I don’t know what i should be
You are right, it appears the gtk-common-themes snap in the candidate channel fixes the theming problem. Well spotted!
I am now trying to bisect what change fixed the problem, and I will talk to the maintainers to have it promoted to stable.
@oSoMoN I noticed that kwallet detection still fails if kwalllet isn’t running before chromium starts. In that case the test call is blocked by apparmor: dbus-daemon[1464]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/modules/kwalletd5" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name="org.kde.kwalletd5" pid=2837 label="snap.chromium.chromium"
If I pass --password-store=kwallet then chromium triggers kwallet start automatically. Is it something fixable or should I force running kwallet before starting chromium?
On a side note I also see quite similar blocked call for bluez: audit[1166]: USER_AVC pid=1166 uid=104 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=2719 label="snap.chromium.chromium"
I don’t use bluetooth so I don’t know what are the consequences of above.
it doesn’t seem to be security sensitive. Is it possible to allow this action by adding something like: owner @{PROC}/@{pid}/clear_refs w, to chromium apparmor profile?
You are right, and the problem is similar for org.freedesktop.secrets if gnome-keyring-daemon is not already running.
I would have expected D-Bus activation to work in this context.
However, in the context of a normal KDE session I would expect kwallet to be running already (and same for gnome-keyring-daemon in a GNOME session). Is this not a safe assumption?
It depends on system settings. I didn’t added kwallet to autostart applications. I also have it set to exit on idle. That means on my system it’s very likely that it won’t be running at the time chromium is launched. I can change it if there is no other workaround however I believe there will be more people hitting this issue and complaining about it.
My concern isn’t about it being harmful but about endless syslog spam. I’m heavy apparmor user and I have set desktop notifications for all denials so this isn’t ok for me. We can forget about bluez but please either allow /proc/PID/clear_refs or deny it but not leave it as is.
