1737305 - LegacyProfile check in PolicyChecks.h should not hardcode Firefox

Status: RESOLVED FIXED

(Firefox :: Enterprise Policies, defect, P2)

Description

[Mike Kaply [:mkaply]]

The LegacyProfile check in PolicyChecks.h hardcodes Firefox so it won't work for Thunderbird.

Comment 1

[Mike Kaply [:mkaply]]

Attachment: Bug 1737305 - Don't hardcode app name when checking LegacyProfiles policy. r?Mossop!

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/216de3cdebc9
Don't hardcode app name when checking LegacyProfiles policy. r=mossop

Comment 3

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/216de3cdebc9

Comment 4

[Mike Kaply [:mkaply]]

Comment on attachment 9247350 [details]
Bug 1737305 - Don't hardcode app name when checking LegacyProfiles policy. r?Mossop!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Policy only, allows LegacyProfiles to work on Thunderbird
• User impact if declined: LegacyProfiles doesn't work on Thunderbird
• Fix Landed on Version: 95
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): policy related only.
• String or UUID changes made by this patch:

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9247350 [details]
Bug 1737305 - Don't hardcode app name when checking LegacyProfiles policy. r?Mossop!

Approved for 91.4esr.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/9904c4118d7d

Comment 7

[Jonathan Watt [:jwatt]]

This seems to break my build because MOZ_APP_BASENAME is not defined, and therefore the value of the define introduced by this bug is a string followed by an identity, rather than two strings that get concatenated. That results in:

 0:10.94 c:/Users/jwatt/mozilla-source/obj/mozilla-unified-no-opt/dist/include\mozilla/PolicyChecks.h(21,35): error: expected ')'
 0:10.94   LONG ret = ::RegGetValueW(aKey, POLICY_REGKEY_NAME, aName, RRF_RT_DWORD,
 0:10.94                                   ^
 0:10.94 c:/Users/jwatt/mozilla-source/obj/mozilla-unified-no-opt/dist/include\mozilla/PolicyChecks.h(14,63): note: expanded from macro 'POLICY_REGKEY_NAME'
 0:10.94 #  define POLICY_REGKEY_NAME L"SOFTWARE\\Policies\\Mozilla\\" MOZ_APP_BASENAME
 0:10.94                                                               ^
 0:10.94 c:/Users/jwatt/mozilla-source/obj/mozilla-unified-no-opt/dist/include\mozilla/PolicyChecks.h(21,28): note: to match this '('
 0:10.94   LONG ret = ::RegGetValueW(aKey, POLICY_REGKEY_NAME, aName, RRF_RT_DWORD,
 0:10.94                            ^
 0:11.33 1 error generated.

Comment 8

[Jonathan Watt [:jwatt]]

My .mozconfig contains:

ac_add_options --disable-tests
ac_add_options --disable-launcher-process
ac_add_options --disable-debug --disable-optimize
ac_add_options --enable-debug-symbols
ac_add_options --enable-profiling

Comment 9

[Mike Kaply [:mkaply]]

MOZ_APP_BASENAME is used in many different places in the build, so this would be breaking in other places if it wasn't defined.

When I had this locally during development, it was because I had to add something to moz.build:

https://searchfox.org/mozilla-central/source/toolkit/profile/moz.build#39

Can you verify that is present in your moz.build? In the mean time, I'll build with your flags to double check.

Comment 10

[Jonathan Watt [:jwatt]]

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

MOZ_APP_BASENAME is used in many different places in the build, so this would be breaking in other places if it wasn't defined.

It breaks pretty early in the build I think, so it might just be the first instance. I put this in the file and it errors:

#ifndef MOZ_APP_BASENAME
#error "........................................................" POLICY_REGKEY_NAME
#endif

I'm wondering if this is somehow related to bug 1740272, but I don't see how... Mitchell, would you have any ideas if this could be related?

When I had this locally during development, it was because I had to add something to moz.build:

https://searchfox.org/mozilla-central/source/toolkit/profile/moz.build#39

Can you verify that is present in your moz.build? In the mean time, I'll build with your flags to double check.

They are, yes. I'm building latest 'central'.

Comment 11

[Mitchell Hentges [:mhentges] 🦀]

I don't think it's related to the new VS tools, because I've installed 2022 as described in comment 2 and 3 here, then done a clobbered build, and everything seems to be happy.

I'm on revision 1bedbf784ec9.

Comment 12

[Jonathan Watt [:jwatt]]

To close the loop on this, I opened bug 1741593. Sorry for the noise here.