1799503 - Find a way to turn off the updater for Firefox Debian Packages installed from an APT repository

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Updates, task)

Description

[Gabriel Bustamante [:gabriel]]

In Bug 1769265 the updater was turned off for using run-time information available in the flatpak and snap application sandboxes. Is there any run-time information we can use to disable the updater when Firefox is installed as a Debian Package from an APT repository?

Comment 1

[Mike Kaply [:mkaply]]

So it occurred to me that we're overthinking this.

If we package the deb, we can just put a file in the package (this_is_a_deb) and check for that file or something similar.

I still think we can look at existing debs, but we can solve this with our own .deb.

Comment 2

[Mike Hommey [:glandium]]

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

So it occurred to me that we're overthinking this.

If we package the deb, we can just put a file in the package (this_is_a_deb) and check for that file or something similar.

Notwithstanding the fact that the filename should not be package-specific (we'd probably want to do the same with other builds), it strikes me that this gives an easy way for malware to stop the updater on non-packaged builds of firefox.

Comment 3

[Mike Kaply [:mkaply]]

They could do that today with policies.json (Or faking the file that is included in the Flatpak)

As is the case on Windows, if the malware has access to the Firefox install directory, they can do anything they want.

Comment 4

[[e-mail] (:bhearsum)]

Is it possible for us to get isPackagedApp set here (and would it make sense to)? We already disable updates when that is set.

Kirk may have thoughts here too.

Comment 5

[Mike Kaply [:mkaply]]

That's what I was thinking, but the issue is how do we know it's a packaged Debian app. We need to check if there is some unique file/situation with the .deb that we can detect.

Comment 6

[Julien Cristau [:jcristau]]

Could we check if our binary (or install dir) is root-owned and disable the updater if so?

Comment 7

[Gabriel Bustamante [:gabriel]]

On this patch I am trying including an is-packaged-app file in the package. Thinking we could check like checking for the /.flatpak-info file? The is-packaged-app would end up in the install directory along with the Firefox binary e.g. /usr/lib/firefox-nightly/is-packaged-app

Comment 8

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

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

Is it possible for us to get isPackagedApp set here

If the Debian folks want to work with us on this (or if we want to package this ourselves), it should be pretty easy to do something like this by modifying the package in some way that we can detect (adding a file, setting a policy, etc).

If not, it may be possible to, like, fish the information that we need out of the package manager. But I am very reluctant to do this for several reasons:

1. I'm not sure that automated testing for this is really possible.
2. It's not clear to me that there is much of an API for doing this and I'm reluctant to write something that is potentially going to need to be changed whenever the package manager changes.
3. Particularly if there isn't a clean API to tie into, it would probably become an issue that we would eventually need to support many, many package manager versions.
4. There are many package managers. I'm reluctant to set the precedent that we are going to tie into them. It seems like it would be very easy for the list of package mangers that we support like this to grow very large. And then the above issues would potentially apply to all of them.

---

(In reply to Julien Cristau [:jcristau] from comment #6)

Could we check if our binary (or install dir) is root-owned and disable the updater if so?

I'm very reluctant to do this. This isn't a very strong signal that updates are being managed.

Comment 9

[Mike Hommey [:glandium]]

The problem with using a file is that it easily becomes a weaponizable way to disable updates on non-packaged installs.

Comment 10

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

(In reply to Mike Hommey [:glandium] from comment #9)

The problem with using a file is that it easily becomes a weaponizable way to disable updates on non-packaged installs.

I feel like :mkaply pretty much covered this in comment 3. If an attacker can modify a file in a package, they can probably also modify policies.json. Or just change the Firefox binary directly.

Comment 11

[Gabriel Bustamante [:gabriel]]

If we add a file to the package we could do something like this https://hg.mozilla.org/try/rev/f776ed4c76ce9bfb6e8e01f91a6c590cfc824dff

Q: Can the updater be disabled at build-time?

We discussed the possibility of adding a distribution_id to the packages to monitor their uptake.

I took a look in searchfox and it seems this id might be set at build-time. Maybe we could turn it off based on that.

Comment 12

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

We could definitely add something that would identify packaged builds that would allow the updater to be disabled. It might also be worth considering just building with --disable-updater.

I'm not sure what the distribution id is. Is this something that could potentially be meddled with by, say, malware? If it is indeed set at build time, it sounds potentially safe.

Comment 13

[Mike Kaply [:mkaply]]

Distribution ID is set at runtime, it goes in the distrbution directory where the app is installed, so it's the same risk as malware setting policies.json.

We could definitely look for a distribution ID at runtime in AppConstants.

And I would love having a distribution ID to tag this.

Comment 14

[Julien Cristau [:jcristau]]

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #12)

We could definitely add something that would identify packaged builds that would allow the updater to be disabled. It might also be worth considering just building with --disable-updater.

We'd much prefer not to rebuild.

Comment 15

[Gabriel Bustamante [:gabriel]]

Attachment: Bug 1799503 - Update Firefox via APT (not balrog) in our .deb packages r?bhearsum,bytesized,mkaply

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/be4ed1d8fd3d
Update Firefox via APT (not balrog) in our .deb packages r=bytesized

Comment 17

[Julien Cristau [:jcristau]]

This will be closed when it hits central.

Comment 18

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/be4ed1d8fd3d