The presenting issue is as follows. The unsigned MSIX packages that we will upload to the Microsoft Store require certain identity values to agree with Mozilla's Microsoft Partner Account. In particular:

Package/Identity/Name                    MozillaFoundation.MozillaFirefoxBeta
Package/Identity/Publisher               CN=193FE5E7-EFE6-4FC4-9D96-D742E0265B78
Package/Properties/PublisherDisplayName  Mozilla Corporation

The signed MSIX packages we produce for enterprises have certain values baked into them that match Mozilla's signing certificate, namely this "CN" value and a few other details. The differing "CN" values mean that the packages cannot contain the same bits.

We can manually produce the packages for the Microsoft Store for a time but eventually we will want to produce both types of MSIX in automation. This ticket tracks updating the msix.py tooling to accommodate these differences and adding automation jobs for the latter.

Package/Identity/Name MozillaFoundation.MozillaFirefoxBeta

I'm quite surprised to see "MozillaFoundation" here (we usually have a very sharp line between Firefox and the Foundation). I assume this has been discussed/dealt with elsewhere, but just calling it out on the off chance it hasn't, and we want to do something about it.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #1)

Package/Identity/Name MozillaFoundation.MozillaFirefoxBeta

I'm quite surprised to see "MozillaFoundation" here (we usually have a very sharp line between Firefox and the Foundation). I assume this has been discussed/dealt with elsewhere, but just calling it out on the off chance it hasn't, and we want to do something about it.

I agree, this is very strange -- but it's determined by our Microsoft Partner Centre account, which is very old. I don't claim to understand anything about it. Maybe :ryanvm has some colour commentary?

That long predates any involvement I've had with the Microsoft Partner Center. I've been looking around in the Partner Center and Azure Console and can't find where it's coming from either.

https://social.msdn.microsoft.com/Forums/windows/en-US/a95779da-3ae6-4584-b303-84e0eeafb406/how-to-change-the-package-identity-publisher-packageidentityname?forum=windowsstore suggests it can't be changed after the initial account setup.

The Azure AD account will be "mozilla" going forward. The new identifiers are:

Package/Identity/Name                    Mozilla.FirefoxBeta
Package/Identity/Publisher               CN=082E9164-EE6C-4EC8-B62C-441FAE7BEFA1
Package/Properties/PublisherDisplayName  Mozilla

and we are hoping to get Mozilla.Firefox for our actual release package. This does raise a question of whether we want to make our self-signed MSIX packages have a different package identifier, so that they can coexist next to the Store installations. A question for a later time.

Some of these values can be computed from the relevant packages and
various defaults, but the logic is sufficiently complicated that I
would prefer to have the values come directly from these configuration
files.

The existing packages like target.installer.msix that are signed
with the "Mozilla Corporation" key for enterprise customers have
package family name like Mozilla.MozillaFirefox. The new packages
that are unsigned for the Microsoft Store are named like
target.store.msix and have package family name like
Mozilla.Firefox. This allows the two to coexist on a single system,
which is most flexible and may prove useful.

https://hg.mozilla.org/mozilla-central/rev/866e12b47128

Nick, I think this may have broken our MSIX packages. The latest set of nightlies are giving me "Error in parsing the app package" when I attempt to install them.

I also noticed that while we're generating the Store versions, they're not getting signed -- so we probably need another taskgraph tweak.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #9)

Nick, I think this may have broken our MSIX packages. The latest set of nightlies are giving me "Error in parsing the app package" when I attempt to install them.

Well, that's not good -- I'll investigate. I thought I had tested this well enough but must have missed something. Leaving the NI for me to follow-up.

I also noticed that while we're generating the Store versions, they're not getting signed -- so we probably need another taskgraph tweak.

Nope, the Store versions are unsigned. In fact, we can't sign them -- the publisher is CN=GUID, and our keys won't match.

Backed out as requested by nalexander

• Backout link

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

I made some small changes to correct the issue, and have relanded. If it wasn't late on Friday I'd probably ask for re-review, but it's unlikely this will make anything materially worse and it should Just Work so we'll have fresh MSIXes for Monday.

The issue was that by using defer=["package-format"] everything within the by-package-format: was left unevaluated. When we finally evaluated it, I wasn't specifying some of the other values. And in fact, by-shipping-product: was never working, because shipping-product was never set. With these changes, I think I've addressed the by-level: issue and I think I've made aurora/devedition by branded correctly too.

https://hg.mozilla.org/mozilla-central/rev/4c8c8bef41cb

(In reply to Nick Alexander :nalexander [he/him] from comment #14)

I made some small changes to correct the issue, and have relanded. If it wasn't late on Friday I'd probably ask for re-review, but it's unlikely this will make anything materially worse and it should Just Work so we'll have fresh MSIXes for Monday.

The issue was that by using defer=["package-format"] everything within the by-package-format: was left unevaluated. When we finally evaluated it, I wasn't specifying some of the other values. And in fact, by-shipping-product: was never working, because shipping-product was never set. With these changes, I think I've addressed the by-level: issue and I think I've made aurora/devedition by branded correctly too.

This appears to be fine: https://ftp.mozilla.org/pub/firefox/nightly/2021/10/2021-10-16-09-48-19-mozilla-central/firefox-95.0a1.multi.win64.installer.msix was signed and installed correctly.

(In reply to Nick Alexander :nalexander [he/him] from comment #16)

(In reply to Nick Alexander :nalexander [he/him] from comment #14)

I made some small changes to correct the issue, and have relanded. If it wasn't late on Friday I'd probably ask for re-review, but it's unlikely this will make anything materially worse and it should Just Work so we'll have fresh MSIXes for Monday.

The issue was that by using defer=["package-format"] everything within the by-package-format: was left unevaluated. When we finally evaluated it, I wasn't specifying some of the other values. And in fact, by-shipping-product: was never working, because shipping-product was never set. With these changes, I think I've addressed the by-level: issue and I think I've made aurora/devedition by branded correctly too.

This appears to be fine: https://ftp.mozilla.org/pub/firefox/nightly/2021/10/2021-10-16-09-48-19-mozilla-central/firefox-95.0a1.multi.win64.installer.msix was signed and installed correctly.

Looks good to me now, too.

Comment on attachment 9245845 [details]
Bug 1728471 - Produce MSIX packages with Mozilla's Microsoft Partner Centre identity values for the Microsoft Store. r?bhearsum!

Beta/Release Uplift Approval Request

• User impact if declined: None. This simply eases relman's life: now they won't have to manually repackage MSIX packages to have the metadata expected by the Microsoft Store; this patch produces them in Taskcluster.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Upon uplift to Beta, the next Beta will produce a target.store.msix. I (:nalexander) or relman (:RyanVM) will upload that MSIX to the Microsoft Store for testing. If the Store accepts the package, then we'll know the metadata as produced by this patch is correct. QE can verify by installing the updated version from the Store.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This impacts only MSIX production, and nothing is relying on these MSIX packages yet.
• String changes made/needed:

Comment on attachment 9245845 [details]
Bug 1728471 - Produce MSIX packages with Mozilla's Microsoft Partner Centre identity values for the Microsoft Store. r?bhearsum!

Approved for 94.0b8.

https://hg.mozilla.org/releases/mozilla-beta/rev/df3e17a5ab50

Hey Nick, do we have a store link for 94 and 95 in order to verify this? Or is there another method we can use? Thanks!

(In reply to Catalin Sasca, QA [:csasca] from comment #21)

Hey Nick, do we have a store link for 94 and 95 in order to verify this? Or is there another method we can use? Thanks!

Are you referring to this: https://www.microsoft.com/store/productId/9NZVDKPMR9RD

(In reply to Catalin Sasca, QA [:csasca] from comment #21)

Hey Nick, do we have a store link for 94 and 95 in order to verify this? Or is there another method we can use? Thanks!

Hi Catalin -- sorry for the delayed response. The Beta Store link is, as of this morning, 94.0b9. We don't have Nightly in to the Store, so this can't be tested for 95. But I'm not worried about it: as long as Release and Beta are healthy (and Beta is, now) we're good to go.

Thanks nawape and Nick for the infos. We installed 94.0b9 without any issues (and updated from 94.0b1 as well). Per Comment 23 (no Nightly in the Store) we can safely close the bug as verified.