User.js: investigate: system add-on updates [Bug 1307563, 1428459]

Created on 16 Jul 2017  路  31Comments  路  Source: arkenfox/user.js

As per this comment

if the automatic update setting is set to "Check for updates, but let me choose whether to install them", it doesn't look like it will ever look for system addon updates at all, much less ask to install them.

This is a concern, because this is exactly the settings we use. System addon updates could be crucial (the mechanism was designed for smaller, rapid deployment of restartless patches) - eg security fix in AutoFormFill, or an exploit patch in pdfjs.

(thanks earthlng)

We should attempt to find out if this is still the case, but I am unsure how on earth we could test it. Maybe we could contact one of the system-addon repos here on github, or maybe @fmarier can help point us in the right direction, or to whom (sorry for throwing your name at you, Francois, but I really have no idea how to go about this)

firefox bug

All 31 comments

The best way forward IMHO would be to file a new bug on bugzilla against the update code and then reference https://bugzilla.mozilla.org/show_bug.cgi?id=1335224#c14.

Notes:

We should attempt to find out if this is still the case

From looking at the nightly code on DXR, it's still the case. Both app.update.enabled and app.update.auto need to be true to reach the code parts where the system addons are updated:

extensions.systemAddon.update.url is only used in 1 function (updateSystemAddons()) and that's only called once and only if appUpdateEnabled is true

https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#124

const PREF_SYSTEM_ADDON_UPDATE_URL    = "extensions.systemAddon.update.url";

https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2484

async updateSystemAddons() {
// ...
   // Download the list of system add-ons
   let url = Preferences.get(PREF_SYSTEM_ADDON_UPDATE_URL, null);

https://dxr.mozilla.org/mozilla-central/search?q=updateSystemAddons&redirect=true

https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/AddonManager.jsm#1508

      if (appUpdateEnabled) {
        try {
          await AddonManagerInternal._getProviderByName("XPIProvider").updateSystemAddons();
       } catch (e) {
          logger.warn("Failed to update system addons", e);
        }
      }

https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/AddonManager.jsm#1363

let appUpdateEnabled = Services.prefs.getBoolPref(PREF_APP_UPDATE_ENABLED) &&
                       Services.prefs.getBoolPref(PREF_APP_UPDATE_AUTO);
const PREF_APP_UPDATE_ENABLED         = "app.update.enabled";
const PREF_APP_UPDATE_AUTO            = "app.update.auto";

Good work there earthlng - thanks. I was looking at AddonManager.jsm earlier, as I followed links from my earlier searches - eg - this comment leads straight to it ( https://bugzilla.mozilla.org/show_bug.cgi?id=1307556#c1 )

I think we should change the note for the update url pref. It makes it sound very scary and as if there are potentially lots of security fixes while in reality most of it is stuff nobody wants.

You can check which updates you would currently get for your FF version:

  • about:config?filter=/systemaddon\.|devtools.chrome/i - set one to true and reset the url
  • open the browser console (ctrl+shift+J) and run UpdateUtils.formatUpdateURL(Preferences.get("extensions.systemAddon.update.url", null))
  • copy the url, load it and press Ctrl+U to view the response in the source code

For me it only wants to install followonsearch and the shield-client at the moment.
If there's ever something useful you can install it from the direct link. Until then let's not pretend that these are important security updates.

FYI: relevant bugzilla 1307563 .. sitting on P3, a year old, and some strange ass ideas being bandied about

Comment 12 sums up the problem nicely. Not 100% sold on the proposed fix.

FYI: Edit: Bugzilla 1428459 - separating system addon updates from app updates (behind a pref?)

Bugzilla 1428459:

we want to remove app.update.enabled

WTF?!

Keeping an eye on it. If they do that then all hell will break loose - it's an important pref eg for ent deployment etc

The same guy also wants a mechanism, that users cannot control (!!!), to push "really important updates" - the super important Mr Robot system addon comes to mind!

FYI, the only reliable way I've found to disable "features" is to use NTFS permissions (on Windows) to deny pretty much all the rights for all users. If I just delete the addOn, it comes back. However, when I try to update Firefox, it complains that the update fails because it is unable to replace the "features" that I've blocked. So /maybe/ distributing "features" separately is a good thing?

^^ same. Update (on portable) fails (due to missing system xpis) but then auto switches to a "full" update and that works - however, I always manually DL and use the PAFs from portableapps - haven't updated via the interface for about 4 releases now

Distributing features separately is a good idea, as long as it can be controlled. Removing the app auto-update pref is a really dumb idea

FYI:
Bugzilla 1307563 was marked invalid as they will handle it in Bugzilla 1428459

They want to remove app.update.enabled;
how will we disable Auto-Update of Firefox? This is really annoying...

Speaking of "Features" - After I updated my FF to 52.6, I went back and again denied ALL permissions to everyone on the pocket/etc files and to my surprise, FF still loaded them! I tried several times; I finally had to delete the darn XPi's...

They want to remove app.update.enabled;
how will we disable Auto-Update of Firefox? This is really annoying...

We'll have to see exactly what they end up doing, and maybe raise some hell. As I mentioned earlier I can see this being a problem with ESR and deployments (all the reasons not to upgrade such as legacy issues, stability etc), and it may be the new group policy thing being worked on is the answer to that, or they may exempt ESR, IDK.

We may be able to block the update URL - but then that would probably block checking for updates as well, may even impact extension updates, IDK.

If they remove the ability for FF users to control when to APP (or EXTension) update then I am sure all hell will break loose as it would break a lot of situations/reasons as already mentioned including developers testing old versions etc (i.e once new versions with this in become old versions) etc

tl;dr: it's a MORONic idea and it better not happen. This is NOT windows 10

Bug 1436851 (group policy: disable system addons updates) did some "changes" to combining PREF_APP_UPDATE_ENABLED & PREF_APP_UPDATE_AUTO in a few places - pretty sure it does not changes the original behavior (removed in two places, re-inserted elswhere) - see https://reviewboard.mozilla.org/r/220332/diff/4#index_header

Oh my,

Now we're asking if users should be able to disable updates at all; Welcome to Microsoft World. Care to jump in those bugs Thorin and ask that the ability to turn off updates remain there?

And I really don't see why we need a "background update agent" - another fallacy "a la Microsoft" (i.e. Click to Run.) Takes all of 30 seconds to update Firefox, don't see a need for a background updater. Not a big fan of storing anything in the registry either, which is where one guy looks to want to store these update settings.

By the way, anyone know how we edit those policies they implemented? Do we need ADMX files? Someone said the policies could be stored in the installation directory (which is where I'd want them) so how do we edit them?

Thank you.

@B00ze64 I added Firefox Enterprise: Policy links on the wiki - you need to be on ESR to use them AFAIK. There's a link for the github policy templates there as well

Thanks. Unfortunately it looks like it's Group Policy on Windows, whereas lucky Unix and Mac get a nice JSON file to play with. Yeah, I read it's for ESR only, but that's what I'm using. How will people on the regular channel control update policies however? Gonna have to watch those bugs...

IMHO:
Until I can't set any preferences over GPO (Group Policy Objects) and until I am stuck with specific upfront configured settings only and also to ESR only... then this is totally useless.
Over-complicated and limited implementation.

And now we have https://bugzilla.mozilla.org/show_bug.cgi?id=1461755

I wonder what we'll end up with. Seems like 10 bugzillas to sort out update prefs for app and system addons. Bit worried about background services pref being "removed" - its required for installed versions t go with pref app.update.enabled (0301a). Otherwise people still get updated on windows. I hope the comment to just hide the UI option is all they do.

At least 1428459 looks like a new pref extensions.systemAddon.update.enabled to divorce system updates from app ones is getting done

see #431

Now that's what I call world-class support! Thanks for adding to the Wiki!

Apparently there is a new pref for automatic updates:
Bug 1420514 - Replace app.update.enabled with app.update.disabledForTesting in update tests.
Presumably this one needs to be set to true?

I'll just wait and see what they eventually come up with, because in all seriousness, I cannot see them completely removing the ability to stop auto-updating

As for changes to app updates, we'll cross those in diffs as we come to them

OK, so https://bugzilla.mozilla.org/show_bug.cgi?id=1460082 landed for FF63+ .. I guess we'll just wait and see what happens

FYI: https://chuttenblog.wordpress.com/2018/06/27/when-exactly-does-a-firefox-user-update-anyway/

so 12 hrly checks, but not if the release is more than 63 days old.... anyway, interesting info from the mozilla guy

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Just-me-ghacks picture Just-me-ghacks  路  6Comments

Thorin-Oakenpants picture Thorin-Oakenpants  路  7Comments

earthlng picture earthlng  路  4Comments

Thorin-Oakenpants picture Thorin-Oakenpants  路  5Comments

grauenwolfe picture grauenwolfe  路  7Comments