1757050 - Build a version of Firefox specifically to be distributed by Linux package managers

Status: NEW

(Toolkit :: Application Update, enhancement, P3)

Description

[Robin Steuber (they/them) [:bytesized]]

Some Linux distributions, like Ubuntu, create their own Firefox builds for distribution via package managers. Apparently other Linux distributions, like Mint, just distribute our builds with a policy JSON file that prevents it from self-updating.

This isn't ideal for a couple of reasons. If a user replaces the provided policy JSON with their own it has the potential to re-enable self-update (while presumably also being updated by the package manager). It also presumably means that the settings page will have the policy warning displayed: "Some settings are managed by your organization".

I think that we should consider providing a build that is more suitable for package managers so that these distros can use that instead.

I do, however, have one large concern. Providing a build with the updater turned off invites the possibility that people will just install it as-is rather than distributing it through a package manager. I'm not sure what the best way to deal with that is. Here are some ideas:

• We could distribute it in some kind of closed way rather than making the builds available to everyone online.
• We could provide the builds in some sort of format that would not be conducive to being installed directly.
• We could somehow check at runtime that the install is managed by a package manager.
• We could check for updates to nag the user about them, but not install them. Or just nag them when the build is sufficiently old.

For reference, this is the config that Ubuntu builds Firefox with (according to about:buildconfig)

--enable-application=browser --host=x86_64-linux-gnu MOZILLA_OFFICIAL=1 --enable-update-channel=release CC=clang-10 CXX=clang++-10 CBINDGEN=/build/firefox-A4y3DG/firefox-91.0+build2/./cbindgen/bin/cbindgen --enable-rust-simd NODEJS=/usr/lib/nodejs-mozilla/bin/node --with-l10n-base=/build/firefox-A4y3DG/firefox-91.0+build2/./l10n --with-google-location-service-api-keyfile=/build/firefox-A4y3DG/firefox-91.0+build2/debian/ga --with-google-safebrowsing-api-keyfile=/build/firefox-A4y3DG/firefox-91.0+build2/debian/ga --disable-elf-hack --with-unsigned-addon-scopes=app --allow-addon-sideload DUMP_SYMS=/build/firefox-A4y3DG/firefox-91.0+build2/./dump_syms/bin/dump_syms --disable-install-strip --enable-crashreporter --enable-official-branding --disable-updater --prefix=/usr --with-distribution-id=com.ubuntu --with-ua-vendor=Ubuntu

Comment 1

[[e-mail] (:bhearsum)]

I share your concerns about having an official build available with this configuration. I wonder if we could simply provide an officially supported policies.json instead of a full build?

I also wonder if we should even consider this an acceptable configuration in a Linux distribution because of the issues you've highlighted. Mint is already an Ubuntu based distribution, so I'm not quite sure I understand why they're not using either of the .deb or .snap packages that Ubuntu makes, or building their own (debian package sources exist, so it doesn't seem like it would be a considerable amount of work).

Mike, do you have any thoughts here?

Comment 2

[Mike Kaply [:mkaply]]

(In reply to [e-mail] (:bhearsum) from comment #1)

I share your concerns about having an official build available with this configuration. I wonder if we could simply provide an officially supported policies.json instead of a full build?

Even if we provide a policies.json, if they replaced it with something they need for their enterprise, it would remove the update disabling

I also wonder if we should even consider this an acceptable configuration in a Linux distribution because of the issues you've highlighted. Mint is already an Ubuntu based distribution, so I'm not quite sure I understand why they're not using either of the .deb or .snap packages that Ubuntu makes, or building their own (debian package sources exist, so it doesn't seem like it would be a considerable amount of work).

Because Mint bundles a distribution.ini, they can't use the Snap and the reason they aren't using the Ubuntu deb is because it is theoretically going away when Canonical goes full Snap. The reason they aren't building their own is because we're trying to encourage folks to use our official builds if they can.

In a perfect world, except for cases where we're working with a partner to build Firefox (Canonical), it would be great if they could somehow use our official builds, hence the idea of building a Firefox without updates enabled.

I wonder if though, to Kirk's point, we could somehow know that Firefox was installed via some other package mechanism and do the right thing?

I don't know enough about Linux packaging to answer that question.

Some other issues around Linux packaging have come up recently so maybe we just need to figure out a better strategy on Linux that might involve producing .deb and .rpm. I think we're the only folks that provide only a tar.bz2 for our application :)

Comment 3

[[e-mail] (:bhearsum)]

(In reply to Mike Kaply [:mkaply] from comment #2)

(In reply to [e-mail] (:bhearsum) from comment #1)

I share your concerns about having an official build available with this configuration. I wonder if we could simply provide an officially supported policies.json instead of a full build?

Even if we provide a policies.json, if they replaced it with something they need for their enterprise, it would remove the update disabling

Yeah, it clearly doesn't help this. I was just thinking about a way to possibly avoid people downloading a build without updates enabled by accident.

Some other issues around Linux packaging have come up recently so maybe we just need to figure out a better strategy on Linux that might involve producing .deb and .rpm. I think we're the only folks that provide only a tar.bz2 for our application :)

We have a little bit of precedent here now -- we ship MozillaVPN through an Ubuntu PPA. Our tooling is not up to snuff for doing anything like that at scale yet, but it's something.

Other applications certainly go further - and host their own debian, yum, etc. repos. Historically we haven't done this because it just hasn't been worth the investment. There's tons of distros with tons of different types of builds & repos. And even if we supported a bunch of them, we'd probably still need a build with our own updater enabled to cover the long tail -- which means we'd be doing everything we do now, plus a bunch of extra distro builds and maintenance of those repositories. (We could decide not to provide any non-distro builds at all, but that I doubt that's a realistic option.)

Comment 4

[Robin Steuber (they/them) [:bytesized]]

(In reply to Mike Kaply [:mkaply] from comment #2)

I wonder if though, to Kirk's point, we could somehow know that Firefox was installed via some other package mechanism and do the right thing?

It seems likely that it is theoretically possible. And it's pretty appealing from a functionality standpoint. But, unfortunately, it's not very appealing from an implementation perspective for a couple of reasons:

1. There are quite a few Linux package managers. It's not even clear to me how we would get a comprehensive list of them. I just spent a few minutes looking into it and the best that I could find was a list of the 22 "best" ones.
2. AFAIK package managers don't really provide a stable API for doing this. And we would likely want to support not only the current version, but also older versions that are still in use. This, combined with the previous point, means that the maintenance burden would probably be very high.
3. It sounds quite difficult to get the needed versions of all the package managers on the test machines. Plus, constantly updating the software on the test machines sounds like it would make it difficult to keep our testing environment stable.
4. If our reaction to "this install is being managed by a package manager" is to not ever update, the security implications of getting this right are high. Which only makes the implementation even more difficult.

Comment 5

[Mike Kaply [:mkaply]]

So then maybe we go back to the original idea.

What if we produced a Linux build that was for all intents and purposes the same as a standard build with updating turned off, packaged it as something that most people wouldn't know to grab and then only offered it to package managers?

The only other thing I came up with (which is probably strange) is that anyone can easily turn off updating by modifying the channel-prefs.js. What if had some custom channel that if you set it, it meant "package manager" and we turned off updates? This isn't making the current situation worse (because people can already turn off updating by modifying channel-prefs.js).

Comment 6

[Mike Kaply [:mkaply]]

Thinking about this more, maybe we're thinking about it backwards. The only version of Firefox that updates properly is our ZIP build with the correct channel.

What if we didn't show update UI if we knew we weren't going to be able to update anyway (like if channel was set to default or something like that).

Today, the easiest way to actually disable updates is change the channel to something invalid. Maybe we should use that?

Comment 7

[[e-mail] (:bhearsum)]

(In reply to Mike Kaply [:mkaply] from comment #6)

Thinking about this more, maybe we're thinking about it backwards. The only version of Firefox that updates properly is our ZIP build with the correct channel.

What if we didn't show update UI if we knew we weren't going to be able to update anyway (like if channel was set to default or something like that).

Today, the easiest way to actually disable updates is change the channel to something invalid. Maybe we should use that?

I'm not going to say we absolutely shouldn't do this, but I'm ever so slightly concerned that if we turn off updates for, eg, default we could get into a bad situation if we also accidentally ship with this channel. (We have had to recover from things like this in the past, although admittedly not for a very long time.) Perhaps it's less of a big deal these days as well, since we could probably recover from such an event with a system addon - but I wanted to write this down regardless.

(Also crosslinking https://bugzilla.mozilla.org/show_bug.cgi?id=1799503, which is discussing similar things.)