2048696 - ExtensionSettings policy ignores REG_SZ when there is a key (Windows registry)

Status: ASSIGNED

(Firefox :: Enterprise Policies, defect)

Description

[Mike Kaply [:mkaply]]

See

https://support.mozilla.org/en-US/questions/1587902

Basically if you create an ExtensionSettings key, the REG_SZ under Firefox is ignored, and the ExtensionSettings keys are parsed.

I've never recommended people do it this way so I'm surprised it works.

We should decide if the ExtensionSettings Key should be ignored or if we should somehow combine with ExtensionSettings?

Comment 1

[Mike Kaply [:mkaply]]

Attachment: Bug 2048696 - Merge a Windows GPO registry value with a same-named subkey instead of dropping it. r?jmendez

WindowsGPOParser read scalar values before child keys and assigned both to
the same policies object, so when a policy was present as both a value (a
REG_SZ/REG_MULTI_SZ holding JSON) and a subkey of the same name -- e.g. an
admin-supplied one-line ExtensionSettings string plus an ExtensionSettings
subkey written by a third party -- the subkey silently overwrote the value.

Merge the two instead, with the value taking precedence on key collisions so
a subkey can't override entries like *. To keep this safe across hives,
parse each hive into its own object and combine at the policy level: a later
hive (machine) still replaces an earlier one (user) wholesale for a given
policy, so an unprivileged HKCU entry can't merge into or shadow an HKLM
policy.

This intentionally diverges from Chrome, which on the same collision discards
the value and uses the subkey alone; merging is strictly more forgiving and is
what this bug asks for. Cross-hive precedence (machine overrides user) still
matches Chrome.