Closed Bug 720527 Opened 13 years ago Closed 8 years ago

Firefox maintenance service should be separate from the services used for maintenance of other Gecko-based products

Categories

(Toolkit :: Application Update, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: briansmith, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #715489 +++

1. If we allow/encourage other products from other companies to replace our update service with our own, then they may break Firefox silent updates. For example, when I install some (hypothetical) nightly build of 30b (a Xulrunner application), it should not replace the maintenance service used for the current Firefox final release, because that nightly build of 30b may include a Nightly (not-production-quality, buggy) version of the maintenance service that could impede Firefox from updating itself.

2. This applies even to special cases of #1, where the producer of the software is Mozilla. For example, the maintenance service that Firefox Nightly installs may have security bugs (like the current situation) and/or fail to work properly for whatever reason. This implies that every channel of every Mozilla product should install its own maintenance service. 

3. People who use Firefox know the "Firefox" brand, but they likely don't know the Mozilla brand. So, it is a good idea to put "Firefox" in the description of the maintenance service so that people understand that it is part of Firefox. This implies making the service for updating Firefox specific to Firefox.
Re 1: I'm not opposed to having a separate service for products outside of Mozilla, and I think that should be the case if we encourage this.

--

Re 2: The original decision was to use 1 service for Mozilla products and channels.  This was described in my blog post as well as the project wiki.  This decision was to avoid having 4 always running services for Firefox alone, and say if Thunderbird uses it, 8 always running services. 

Since then we switched to on demand services, so that argument is not as strong; however, it does seem a bit strange to me to have 8 or more of the same services in Windows.

I should mention that even if you have a Nightly installed service, it still uses the updater.exe to perform the actual update from whatever channel the update is being applied for.  So if there are changes to the update process over time, they will be per channel, because they will be made in the updater.exe code. 

> For example, the maintenance service that Firefox Nightly installs may 
> have security bugs (like the current situation)

The security problems you speak of are not directly touching any of the maintenance service code nor are they limited to the service. In fact you can even apply the patches independently of the service patches before the service landed to correct the existing security problems.  
Your statement about the security problems being in the maintenance service is wrong.  At least relating to the ones identified to date that you are referring to when you say "like the current situation".

The security problems are more exposed to limited user accounts from the service but only because we are opting for limited user accounts to perform updates.  Since we want this we set ACL on the service to be started by members of the users group instead of the admin group, we could easily change that to admin if you prefer in the context of another task so only admins can start the service.  This would be 1 line of code change.  In this way the existing security problems would have equal parity with the service. 

--

Re 3: This is already done in the context of bug 715489.
We have not run into any problems with the single service and we aren't going to install a separate one for each Mozilla product. It is important to note that even if we did there wouldn't be a decent way of preventing another product from overwriting us if they chose to and had privileges to do so.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.