1462542 - Firefox 60 ESR (win 32/64) writes registry full of "targetIDs"

Status: NEW

(Firefox :: Installer, defect, P3)

Description

[ronronron]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180503164101

Steps to reproduce:

Regarding to this Bug 1324617:
https://bugzilla.mozilla.org/show_bug.cgi?id=1324617

I was told that I opened the "bug" in the wrong forum:
https://support.mozilla.org/en-US/questions/1217940

So, somebody opened the Bug 1324617 and it got fixed for the normal Firefox branches, but now you "fixed" this "bug" in the Firefox 60 ESR version, too.

As I told in the other forum post:
I can understand that Bug and Fix, but only for normal/private Users, with maybe different installations.

In the Bug-report you can see that all persons are reporting it for the standard versions and not the ESR one! (https://bugzilla.mozilla.org/show_bug.cgi?id=1324617)

But in an enterprise environment (I think ESR was especially made for this), I guess the standard is one Firefox Version and Installation.
So this change makes absolutely no sense.

In our enterprise environment we make a lot of automatic settings and configurations with Windows GPOs and now with this so called "bugfix"  we have to rework every single GPO.

You can't be serious that we have to change this things with every single ESR Version upgrade from now on...

It appeals that this fix is missing the point of ESR itself and if there will be no change, we have to search a new standard browser for our thousands of windows clients...


Actual results:

The registry is now full of "wrong" entrys, like this one:
before
"Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Firefox"
"Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML" 

now
"Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\Firefox-3EF782B73E4DE8EA"
"Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\FirefoxHTML-3EF782B73E4DE8EA\shell\open\command"

or in 60.0.0ESR [HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications] -> "Firefox-3EF782B73E4DE8EA"="Software\\Clients\\StartMenuInternet\\Firefox-3EF782B73E4DE8EA\\Capabilities"

and in 52.8.0ESR [HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications] -> "Firefox"="Software\\Clients\\StartMenuInternet\\Firefox.exe\\Capabilities" 


Expected results:

For example we are using Windows GPOs for opening stuff with selected programs which are linked in the regarding registry entries, but lots of other stuff, too.

I hope that you get my point and will change it for the ESR version back to previous way.

Comment 1

[Molly Howell (she/her) [:mhowell]]

A couple of points about this feature that seem to have been missed:

- The changes discussed here are not made when updating an installation from 52 ESR to 60 ESR. The old registry key names will be kept. This is true regardless of how the update is installed; it doesn't matter whether the update is applied manually by running the installer or automatically by our built-in updater. The new names are only used for entirely new installations.
- The ID isn't a random string that changes on every update, it's a hash of the installation path. It should never change at all, and it will be the same on every machine that uses the same install directory.

That said, I have to admit that I did not consider anyone directly making use of the names of these registry keys when I wrote the patches that we're talking about, and I'm not sure that these points mitigate the problem successfully; it seems like you'd still have to somehow manage new installations separately. We may have to add an option to disable this behavior for ESR. Mike, what do you think?

Comment 2

[Mike Kaply [:mkaply]]

I think I'd like to hear from Ron since he opened the bug.

If this is a one time change, it doesn't seem that bad.

I'm not sure I want installers to diverge between ESR and RR.

Comment 3

[ronronron]

It would be awesome if you can fix it.
We make new-installations everytime, no updates.

I think the ID changes at least at every version upgrade (I saw that 45ESR, 52ESR and 60ESR have different IDs).
So it would be a "one time change" every version upgrade, but all "old" installations wouldn't get the new Windows GPOs.

Comment 4

[Jim Mathies [:jimm]]

(In reply to ronronron from comment #3)
> I think the ID changes at least at every version upgrade (I saw that 45ESR,
> 52ESR and 60ESR have different IDs).
> So it would be a "one time change" every version upgrade, but all "old"
> installations wouldn't get the new Windows GPOs.

We added a hash to the key name that represents the install path location, so the ID will not change across upgrades *assuming* your ESR deployments always place the browser in the same location. For example, on my system I have ESR in 'C:\Program Files\Mozilla Firefox ESR'. You'll only have to update your GPO configs once when you migrate to 60.

We're sorry to place this burden on you but occasionally we have to make changes like this, and we prefer to keep things operating the same regardless which release a user is using. This insures coherence between releases, which makes our support teams job less complex. (..and improves our support reliability!)

I'm leaning toward wontfix here because we don't want to support both registry key generation methods going forward.

Comment 5

[Scott Copus]

(In reply to Jim Mathies [:jimm] from comment #4)

Hi Jim. Is the reasoning behind the key name hashing to support different Firefox releases/versions on a single system?

I'm just trying to understand it to see how this relate to our Windows build & maintenance environment at our own university.  We use the "default browser" group policy setting for Windows 10:
  https://docs.microsoft.com/en-us/internet-explorer/ie11-deploy-guide/set-the-default-browser-using-group-policy

This employs a "default associations configuration file". Our file currently just points to IE for now:
  <Association Identifier="http" ProgId="IE.HTTP" ApplicationName="Internet Explorer" />
  <Association Identifier="https" ProgId="IE.HTTPS" ApplicationName="Internet Explorer" />

But if we decide to change to Firefox in the future, does this discussion also relate to this?  I don't know how "ProgID" relates to previously mentioned "IDs".  If these "ProgID" values start varying for something OTHER than a just the Firefox installation path, then I see this becoming very challenging to start maintaining Firefox as a default web browser on Windows 10 devices using GPOs.  Assuming the install path doesn't change, is that key name hash consistent across every different devices and different releases/versions of Firefox?

thanks,
Scott

Comment 6

[Florent]

In the beginning i was thinking it was bad.

But i see the ID refer to installation path is good idea to maintain multiple installation of Firefox for different needs.
If you assure no new change for future version.
Changes was minor with GPOs, just add id in the xml file.

I think consitency between ESR and RR must be kept about this.

Comment 7

[Molly Howell (she/her) [:mhowell]]

(In reply to Scott Copus from comment #5)
> (In reply to Jim Mathies [:jimm] from comment #4)
> 
> Hi Jim. Is the reasoning behind the key name hashing to support different
> Firefox releases/versions on a single system?

That's exactly the idea, yes. Before this change only the most recently installed copy/version of Firefox was available to set as the default browser or in the file association UI, which was certainly not a great experience.

> But if we decide to change to Firefox in the future, does this discussion
> also relate to this?  I don't know how "ProgID" relates to previously
> mentioned "IDs".  If these "ProgID" values start varying for something OTHER
> than a just the Firefox installation path, then I see this becoming very
> challenging to start maintaining Firefox as a default web browser on Windows
> 10 devices using GPOs.

We don't have a documented promise that the ProgID will never change again, but more than anything else that's because I never realized it was something that people were directly using. Now that I do realize that, I can't imagine a reason it would ever need to change again and I would certainly go out of my way to keep that from happening.

Additionally, Windows strongly discourages us from changing it; if we're set as the default browser and our ProgID changes (i.e. during a Firefox update), the default browser generally gets reverted to Edge as a security measure because Windows assumes that some malware is trying to override the user's setting. So I had to go to great pains to make sure that we don't update the ProgID for any copy that was already installed prior to that change. It was a ton of work, I didn't get it right the first time and had to fix a couple of followup bugs, and I'm not in a hurry to relive that experience.

> Assuming the install path doesn't change, is that
> key name hash consistent across every different devices and different
> releases/versions of Firefox?

Yes, there has only ever been one method of calculating the hash; it's just the CityHash64 algorithm run over the long path of the install directory with no trailing backslash. You can also get the hash for an installed copy from the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Firefox\TaskBarIDs, which is a key that contains one value for each install, the name of the value is the install path and the data is the hash as a string.

Comment 8

[Scott Copus]

(In reply to Matt Howell [:mhowell] from comment #7)

Thanks Matt for the excellent feedback and also for the good news about the ProgID hash planning to remain consistent moving forward. Hopefully comments about this or links to this bug will be in the source code soon so current and future devs know to not change it. It's also too bad that Windows does a terrible job of security and implements crazy protective measures as a workaround. Windows should have APIs for everything instead of a direct-access "registry" to avoid all kinds of problems and confusion, but I digress...  Cheers.