1897155 - [MSIX] msix Nightly 128 build cannot be installed over a msix Nightly 127

Status: NEW

(Firefox :: Installer, defect)

Description

[Brindusa Tot, Desktop QA]

Attachment: Windows 10 error

Found in

• Firefox 128.0a1

Affected versions

• Update from .msix Firefox 127.0a1 to Firefox 128.0a1

Tested platforms

• Affected platforms: Windows 10, Windows 11

Steps to reproduce

1. On Windows 10, install a .msix (2024-05-02) Firefox nightly build: https://archive.mozilla.org/pub/firefox/nightly/2024/05/2024-05-02-09-16-33-mozilla-central/firefox-127.0a1.multi.win64.installer.msix
2. Start Firefox, make sure it is working properly
3. Close it.
4. Install the .msix Nightly build from https://archive.mozilla.org/pub/firefox/nightly/2024/05/2024-05-15-03-23-56-mozilla-central/firefox-128.0a1.multi.win64.installer.msix

Expected result

• The new build .msix Nightly 128.0a1, from 2024-05-15, should be installed successfully over the one installed at step1

Actual result

• The new build .msix build from 2024-05-15 is NOT installed, with error:

App installation failed with error message: Windows cannot install package Mozilla.MozillaFirefoxNightly_128.2405.1503.0_x64__jag0gd4e3s9p2 because a different package Mozilla.MozillaFirefoxNightly_127.2405.209.0_x64__gmpnhwe7bv608 with the same name is already installed. Remove package Mozilla.MozillaFirefoxNightly_127.2405.209.0_x64__gmpnhwe7bv608 before installing. (0x80073cf3)

Additional Notes

1. On Windows 11, after step 4, the update prompt is not received but instead a new instance of Firefox Nightly is installed. At the end, we have 2 MozillaFirefoxNightly installed 127.0a1 and 128.0a1.
2. If at step 4, I am using build from https://archive.mozilla.org/pub/firefox/nightly/2024/05/2024-05-15-20-24-18-mozilla-central/ , all works correctly. Please note that between the two builds bug 1889299 was backed out.

Comment 1

[Nick Alexander :nalexander [he/him]]

The issue here appears to be that the "publisher ID", namely the jag0gd4e3s9p2 bit, has evolved from gmpnhwe7bv608. (See this opaque comment around https://searchfox.org/mozilla-central/rev/a18a7c526cf3c531f2fc24db4f0dffbc16290a7e/python/mozbuild/mozbuild/repackaging/msix.py#504-510.)

I don't think this value is under our control; it's derived from the package identity and other details that we supply. I will try to understand if anything can be done here. N.b. I expect this to not be significant for Microsoft Store builds, because IIRC Microsoft resigns our MSIX packages for Store delivery, and presumably their signing key is stable.

Comment 2

[Nick Alexander :nalexander [he/him]]

Looking even earlier, Bug 1894145 was landed in https://hg.mozilla.org/mozilla-central/rev/6c8cd1a8cb0b177faccc9ce38f009dc05148e72d and immediately backed out. But the last Nightly without that commit, namely https://archive.mozilla.org/pub/firefox/nightly/2024/04/2024-04-30-09-47-38-mozilla-central/firefox-127.0a1.multi.win64.installer.msix cannot be installed at all -- the signing key and the manifest publisher don't agree, and that's not valid. And indeed, all of the MSIX tests failed: https://treeherder.mozilla.org/jobs?repo=mozilla-central&searchStr=msix&revision=0c6cd807867dbaf592b3c7db4eef81220fe03acf.

I think we need to produce a signing key with the same metadata. bhearsum, is that possible?

Comment 3

[Nick Alexander :nalexander [he/him]]

OK, it looks like Windows 11 accommodates this with a possibly difficult process (see https://github.com/microsoft/msix-packaging/issues/365), that Windows 10 may not accommodate this (see https://github.com/microsoft/msix-packaging/issues/624). The process documentation is at https://learn.microsoft.com/en-us/windows/msix/package/persistent-identity.

Comment 4

[Nick Alexander :nalexander [he/him]]

I'm confident that we can arrange the persistent identity process, since our existing signing key is still valid. But it's clear that the persistent identity process is Windows 11-only, and therefore that obtaining a signing key with our existing metadata is valuable. Right now we have roughly 2x Windows 11 users as Windows 10 MSIX users: see https://sql.telemetry.mozilla.org/queries/99972/source?p_date=d_last_14_days#246437.

Comment 5

[[e-mail] (:bhearsum)]

This has been discussed on Slack a bit. According to our SRE who deals with cert aquisition:

We’ve updated our organizational information at digicert at least twice in my memory, 650Castro -> 331Evelyn -> 149 New Montgomery. They do some out-of-sight-of-us research into us, I believe it’s “look the applicant up in Dun and Bradstreet” / “legal paperwork is in order” type things. I doubt we can pass off as anything from that far back.
It’s been a while since I paid attention, but I remember there was a point at which I sent up a CSR that asked for L=Mountain View (because lazy CSR generation) and it got stomped to L=San Francisco because of org-level validation taking priority.
It’s late here and I’m just going from memory without trying/asking, but I don’t think the “new cert with old metadata” will pay off.

https://github.com/microsoft/msix-packaging/issues/365 is also relevant reading for general complaints about this issue, and other ways you can unwillingly end up with an identity change.

Comment 6

[[e-mail] (:bhearsum)]

One other thing to note: I think the change to package identity will cause data loss for any users whose profiles are stored in the virtualized filesystem. I haven't verified this, but I think this is what we would expect based on my understanding of how that works.

Comment 7

[Julien Cristau [:jcristau]]

I had a look last week at what the "persistent identity" route would involve. AFAICT osslsigncode gained support for signing cat files in https://github.com/mtrojnar/osslsigncode/pull/63, so we'd have to update to a version that includes those changes (we currently use 2.1), and then teach https://github.com/mozilla-releng/winsign how to handle those files. winsign currently uses osslsigncode attach-signature to stuff the signature into the file, but that's not supported for cat files (https://github.com/mtrojnar/osslsigncode/blob/825c9dad7cd139378b4288aa09e7e1e4fec5cdc5/cat.c#L84), so there's a bit of research/engineering to do there; I didn't pursue it further.