[BUG] Package cannot automatically update when the signing certificate has changed

[jagbarcelo]

Project MSIX SDK (Package created using VS Community 2019 16.6.4)

Describe the bug Package cannot automatically update when the signing certificate has changed.

To Reproduce

1. Sign and deploy your application using a certificate. You keep on using it and updating your app, and your user base grows.
2. Later on (two years in our case) the certificate is near expiration and we ask for another one. Due to changes in the Certificate Authority, or even ourselves if we move from one location to another, or whatever the reason, the new certificate is slightly different (maybe now it is all uppercase letters in the CN field).
3. Sign (with the new certificate) and deploy again your application, but in this case none of your users can update because of the following EventLog error (channel: Microsoft-Windows-AppXDeploymentServer/Operational):

Error	04/08/2020 12:44:09	AppXDeployment-Server	651	(3)
Error en la operación AppInstaller con el código de error 0x80070490. Detalle: No se ha encontrado el elemento.

If users manually force the installation of the package browsing to the webpage where it is published (by clicking in the "ms-appinstaller:?source=https://the.web.site.com/AppPackages/PackageProject.appinstaller" hyperlink) they receive the following error message:

The translation goes like:

Ask the developer for a new app package. This package may conflict with a package already installed, or it depends on things not installed here (package dependencies), or is made for a different architecture (0x80073CF3)

And in the EventLog (same channel as before):

Error	04/08/2020 12:58:35	AppXDeployment-Server	429	(4)
Windows cannot install package 967439b3-5b2b-4167-839c-0ba174a6c946_3.2.17.0_neutral_~_cb1zszxp1a70a because a different package 967439b3-5b2b-4167-839c-0ba174a6c946_3.2.16.0_neutral_~_wytc7bwvwy2aa with the same name is already installed. Remove package 967439b3-5b2b-4167-839c-0ba174a6c946_3.2.16.0_neutral_~_wytc7bwvwy2aa before installing.

Summing up, a conflict with a package with the same name that already exists, because the update is detected as a different package.

Expected behavior There should be a way to keep on updating our applications despite changes in the signing certificate. Because of a company moving from one city to another, or a Certifcate Autority changing its policies (now enforces everything in upper cases). That shoudn't mean that our whole user base must do a manual uninstall and reinstallation of the application.

Screenshots If applicable, add screenshots to help explain your problem.

Platform x64 and x86 at least. Not tested in any other.

Additional context This thread Updating existing app with new certificate UWP deals with the same problem. I suppose it does not matter what kind of target application you are making since the issue comes at the core of the distribution process. It is not so much what you are publishing but more the way to do it.

[SeriousGeorge]

Thanks jagbarcelo for figuring this one out. I can confirm this.

We have the exact same issue. Our certificate ran out in May 2019, we updated to a new one (until 2021).

Result: All users who have the app with the old certificate installed, can't update to any new version with the new certificate since May 2019, without seeing the error message "this package may conflict with a package already installed".

Installation in our case: Also via an update url with appinstaller file.

[Psykobal]

We ran into this issue too, our Certificate Authority changed the "State" field (from shortname to fullname). We had to manually uninstall all apps, install the update and configure them again.

The issue is the "Family name" (app manifest -> Packaging tab). This name is a Hash of all the characters in the signin certificate. This family name is used as installation folder. You can't set it and if it changes you have to uninstall/install again manually and lose all your previous configurations.

We thought about leaving .appinstaller (and UWP) because of that (it will be extremely painfull to do it again at every changes of CA policies). It's pretty sad because the auto-update and remote installation functionalities are awesome!

One fix is to use a self-signed certificate (you can copy/paste the fields of the old certificate) but it feels unprofessional.

[jagbarcelo]

This problem could be solved if the "Family name" was editable or if, at least, there were an alternative "Family name", call it Custom, Legacy or Migration that could be used solely for application updates, from one old Family name (due to the expiring certificate) to a new Family name (generated with the new certificate).

Right now renewing our signing-certificates is far from being painless for us, developers.

[TimMangan]

I have a different scenario with the same cause. The package is made available via the Windows Store but also because of customers where store access is blocked also may obtain it directly from my website. Obviously I can't use the Microsoft Store cert when I distribute myself, so a customer that originally obtained the store version cannot upgrade.

[dmiller02]

We have had this issue the last week or so. Our problem was caused by the subject name having been changed on the re-issue of the certificate. Once we corrected this our issue was resolved.

We are deploying via a URL and appinstaller.

[Psykobal]

Any update on this? We ran in this problem again, this time the CA removed street address and postal code. (https://www.leaderssl.com/news/527-from-march-1-2021-sectigo-will-remove-street-address-and-postal-code-information-from-all-public-certificates)

[TimMangan]

I now have the issue in a way more common with all of you. I have been through two different CAs (Sectigo and Digicert) and they both refuse to include the additional fields that were in my previous certificate. Thus my customers cannot upgrade. and must manually uninstall / install. The certificate should not cause package lineage to fail. Either fix that or give us an additional field in the AppXManifest used to generate the PublisherId hash used in Package Family Name.

This issue is also mentioned in the Tech community galley here: https://techcommunity.microsoft.com/t5/msix-deployment/how-and-why-publisherid-packagefullname-and-ca-s-break-the/m-p/2494204

[dianmsft]

We introduced a new feature that is currently in an Insider Build that tackles the issue of packages unable to update due to signing certificate changes. Here is the link to the documentation: https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity

[TimMangan]

Step 4 : Sign the catalog with the old certificate. The old certificate has expired. Is this process going to work?

[Psykobal]

You can find at the end of the article:

In order to leverage this feature, you will need to do this before the old certificate has expired.

It seems not

You will still need to install the old certificate (recommended with timestamp) on the machine for the platform to install the package that was signed by the new certificate.

Ours machines or customers?

It's currently in the Insider Build, but will it be available for currents versions of Windows (1909, 2004, 20H2, 21H1)?

[jagbarcelo]

Two years later and this issue is still making our lives miserable. Our certificate is near expiration again and we've just asked for a new one. This time (again) the CA has changed some fields and our new certificate (again) does not have the exact Subject information in it.

According to Persistent Identity documents seem incomplete (or feature is broken), and makeappx gives uninformative error message, "the device will need to have the old certificate in order to install the package and use this feature", meaning that we need a way to install the old (expiring) certificate in our users machines, in order for the "MSIX persistent identity" to work at all. This means not only for existing customers (for upgrading) but also for new installations (really???). At least that's what is implied after reading the 2nd consideration and the comment posted by @dianmsft in https://github.com/MicrosoftDocs/msix-docs/issues/304#issuecomment-1159260121 in the former issue.

Again, we are forced to follow the least friction path and ask our user's to manually uninstall the program, reboot and reinstall it again in order to keep on receiving updates. The workaround described in https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity is completely useless as it is now (besides not being described in enough detail).

[TimMangan]

This is not an acceptable process.

CAs require certificate renewal every year so this process says I'd have to start building chains of expired certificates for the catalog. In four years I'll be telling them, yeah just install these 4 expired certificates on all of your systems and then you can install this product. And not only for the upgrade, but also a net-new company getting this software for the first time.

Unacceptable for the software vendor, and certainly not acceptable for the customer. There is no world in which I would advise the customer that they should install and rely upon an expired certificate. So, I guess I'll be telling customers to uninstall and reinstall again this year.

I guess that being its own CA, Microsoft never has to deal with these issues. But how are you going to move your partners to want to release as MSIX like this?

[florelis]

I understand that this process is awkward at best, so I want to offer some insight to at least explain some of it.

Ensuring that an update to an app comes from the same publisher is very important. If someone manages to take over the identity of an app in an update, they would have access to the app's data (like credentials stored in a Credential Locker) which isn't good. The way this is prevented is by ensuring that the app is signed by the same entity. The issue is that if the cert subject changes there is no easy way to be sure that the new and old certificates belong to the same entity. I know it is problematic for you to not be able to update your app in that case, but that same mechanism is what prevents an attacker from hijacking it.

What the Persistent Identity feature provides is a way for you to let the OS know that two different subjects refer to the same entity. If the cert subject changes from A to B, this is done by having an artifact stating "A is also called B" that is signed by A. Now, to be sure that the artifact is legit (and not faked by an attacker), the signature needs to be valid. That means that it was created before cert A expired, that the system trusts on cert A, and that the artifact is timestamped (if past the expiration).

If you have any suggestion of how to make it easier while still being secure, I can bring it to the team for consideration.

[TimMangan]

Here is a summary of my thoughts on this.

1. Code Signing of a package does not equal identity. Code signing is only a promise that the package has not been touched since the signer signed it. Loss of the certificate password (as is believed to have happened to one well-known vendor leading to attacks) means anything could be in code signed by the cert.
2. Customers should not equate code signed by a cert as being automatically safe in their security procedures. Hashes, while not perfect, are the best thing we have. Having a known hash of a package that you have verified does equal package identity. Customers interested in identifying software that is safe in security systems (such as App Locker or WDAG) should be using allowed software identified via hashes.
3. The most important job of a public CA is to ensure that they know the customer that they provide a certificate to is that customer. The part of the certificate that uniquely identifies the certificate owner is contained in the Subject field, just not the entire field. It is the “CN=” portion of that field.
4. Public CAs alone control the syntax provided in the subject field. As a software vendor requesting a certificate from them, I provide a CSR that contains information that they will use to generate the certificate, but the software vendor has absolutely zero control over what that subject field will contain. The public CAs that I work with have a standard that they implement, apparently through a software algorithm (because every CA employee I talk to tells me they have no control over what the output syntax will be). These algorithms can change, and they have for me each of the last two years. Furthermore, even though I purchased a 3-year certificate they issue it in only 1 year validity, and I must use a renewal process to get a valid certificate each year. This renewal process will use the then current algorithm to generate the subject field.
   • Last year, the algorithm had changed to remove the “POSTAL=” field. I was told that this was for my security, but since the rest of the address can be gleamed from the certificate I didn’t feel any more secure. • This year, the algorithm has changed to always include an “OU=”, and even if one is not provided in the CSR they just duplicate the “O=” field using it.
5. The idea that MSIX wants to use Persistent Identity of the software publisher is a good idea. It is the implementation of that idea that is deeply flawed. By depending on the full subject field which is arbitrarily changing, there is no persistence.
6. It isn’t my role to tell you how to fix this. The current process of using the current Persistent Identity implementation is leading to a change package identity due to the hash generated from the full subject field. This then leads to a different package identity each year, preventing the custom from having a smooth upgrade process. The workaround that requires using expired certificates is a non-starter.

I don't know how you can fix this without breaking everything first, but something needs to be done or you will see many vendors staying with/returning to MSI deployments.

[TimMangan]

Oh, I left off one more thing. Any persistent identity solution for the software publisher should also cover the scenario where the name of the publisher changes due to merger/acquisition.

[jagbarcelo]

@lechacon

If you have any suggestion of how to make it easier while still being secure, I can bring it to the team for consideration.

Let's try and made up an scenario where we have a near-expiry certificate, let's call it Old-Cert, and another certificate New-Cert. Both certificates have an overlapping window where both are valid (the old one is not yet expired and the new one is already issued and valid). This is the only prerequisite for the procedure that is described below (an overlapping window).

Let's suppose we have a MSIX application that has been released for quite some time, always signed with the Old-Cert. In the next image these releases are Release A and any other release before that one, in red.

Now, we reach the point where a new version is required to be launched into market (Release B). This time we have both certificates available but the developer will still sign that release with the Old-Cert. Besides that, and here comes the interesting step, the public key of the New-Cert will also be signed (using private key of Old-Cert) timestamped, and included in Release B.

That public-key of New-Cert, being signed with the private-key of the Old-Cert is the only key-chain that the MSIX upgrade subsystem will need to ensure that, whenever a new release comes into play (Release C in the image) it will be a valid one: the new release will be valid if it still comes signed with the Old-Cert or by the New-Cert that was preapproved in an earlier release (Release B).

Finally, the time comes to launch Release C, that will be signed only with New-Cert. When the MSIX upgrade is launched, it will see that it is not signed with Old-Cert, but it is signed with the New-Cert which was preapproved in an earlier release, and will proceed and install the upgrade as normal (maybe it needs to change the target directory of the application, since the Family Name might probably change).

There is no need for a Persistent Identity as it was defined in https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity. We only need a way to create a single-point-in-time continuity between two different certificates, and that can be ensured by simply signing the public-key of the new one with the private-key of the old one.

@TimMangan

Oh, I left off one more thing. Any persistent identity solution for the software publisher should also cover the scenario where the name of the publisher changes due to merger/acquisition.

I think this solution would work in your scenario too. It would not matter if any field in the New-Cert matches or not any in the Old-Cert, since the approval derives from the fact that the New-Cert was signed by the Old-Cert as a legit succesor of it.

The only drawback that I can think of this procedure is the case where some users seldomly used the application, they skipped Release B, and tried to update from Release A to Release C (without knowing of Release B because they didn't open the application during the time it was published). In that case the upgrade will fail, since they didn't go through Release B which set the foundations for the certificate upgrade. However, in order to minimise the chances of that scenario to happen, the developer could release several versions of the application (Release B1, Release B2, Release B3... during an extended overlapped window), all of them including the signed New-Cert, and approving it as a legit new certificate for any later release.

Any one sees any flaws in this procedure? Could it be implemented something like this in the MSIX upgrade subsystem?

Just my two cents (I hope they're worth more than that). Regards.

[TimMangan]

It is my understanding that a brand new customer receiving Release B or Release C will be required to install Old-Cert to be able to install the release. This is not reasonable. Nor is it reasonable to require me to release a "Release-B as upgrade" and separately "Release-B as new" in parallel.

Maybe the doc confused me about that requirement, but that is how I read it.

[jagbarcelo]

It is my understanding that a brand new customer receiving Release B or Release C will be required to install Old-Cert to be able to install the release. This is not reasonable. Nor is it reasonable to require me to release a "Release-B as upgrade" and separately "Release-B as new" in parallel.

I don't think that any brand-new users installing Release B would require anything particular to be installed. Release B would be signed with the still-valid Old-Cert, just as any other any earlier releases (Release A and previous ones).

On the other hand, brand-new users installing Release C directly, would never know there was a previous Old-Cert at all.

In no case, final users would need to install any certificates (expired or not) in their local machines. My request is that the MSIX upgrade subsystem should be modified to allow upgrades in the app whenever any of these two things happens:

• The certificate signing the new release is exactly the same as the previous one (old behaviour), or...
• (this is the new behaviour) The certificate signing the new release is a preapproved certificate (a different certificate that was previously signed with the old one). Of course, in order to do this check, the signed new certificate should be stored somewhere; probably the registry or the app directory itself, but that would be left up to the implementation of the MSIX upgrade procedure itself. I no case any of the old nor new certificates should be installed in the certificate stores of the users' machines.

[florelis]

@TimMangan

Loss of the certificate password […] means anything could be in code signed by the cert.

I'm no expert in PKI, but I think that's what revocation is for.

Customers should not equate code signed by a cert as being automatically safe in their security procedures.

Yes, something being signed is no proof that it is safe. But if an app is signed by anybody but the publisher, that's a pretty good sign that somebody may be trying to impersonate the publisher and the app is not safe.

The part of the certificate that uniquely identifies the certificate owner is contained in the Subject field, just not the entire field. It is the “CN=” portion of that field.

I don't think that is true. For example, the names "CN=Jane Doe, C=US" and "CN=Jane Doe, C=UK" probably refer to different people.

using expired certificates is a non-starter.

Could you expand on why you think that? The expired certificate is not used to sign anything new (not sure if any tool would even let you do that). Instead, it is used to sign the artifacts before it expires, and the timestamp proves that it was valid at the time of signing.

[florelis]

@jagbarcelo

Both certificates have an overlapping window where both are valid (the old one is not yet expired and the new one is already issued and valid). This is the only prerequisite for the procedure that is described below (an overlapping window).

That's more or less the same as for the existing feature :)

the public key of the New-Cert will also be signed (using private key of Old-Cert)

This part is basically what the Persistent Identity feature does. Only that instead of endorsing the key/cert, we endorse the cert subject; and the artifact goes in new version instead of the old one. That way, if you re-new your certificate again and are able to preserve the new subject name, the same artifact would still work.

Now, we reach the point where a new version is required to be launched into market (Release B). This time we have both certificates available but the developer will still sign that release with the Old-Cert.

This is only possible if the release schedule lines up with having both certs. With the current feature, you can generate the signed artifact during this time window, then sit on it until you are ready to publish a new release and include the artifact in it even if the overlapping window is now long gone.

The only drawback that I can think of this procedure is the case where some users seldomly used the application, they skipped Release B, and tried to update from Release A to Release C (without knowing of Release B because they didn't open the application during the time it was published).

I see that as a pretty big drawback. The feature as it is now was designed so that upgrading would work between any two versions, regardless of how many you skip.

the developer could release several versions of the application […], all of them including the signed New-Cert, and approving it as a legit new certificate for any later release.

I'd expect that to not be possible in most cases due to the overlapping window being too small to fit more than one release. For example, with an app released twice a year with a cert expiration of 1 year, you would only be able to use the same cert for two releases, and the overlapping window will be even less than that.

since the Family Name might probably change.

Yes, it would change as it is derived from the package name and the publisher name (which matches the cert subject). Which is a problem as it is supposed to identify a package across versions and it is used in different places. For example, the Shared Package definition uses it and Package Dependencies are defined in terms of Name + Publisher.

[TimMangan]

@dianmsft I am going to try out the process of including the catalog, under the assumption that the line in the Persistant Identity doc that says "You will still need to install the old certificate (recommended with timestamp) on the machine for the platform to install the package that was signed by the new certificate" in the document is being mis-understood by us and that the expired certificate does not need to be installed on end user systems. If I can prove that this works we can simply request a rewording of that line.

The question becomes how to trick WAP Publishing in Visual Studio to include the /pb option when makemsix is run? Is there an underdocumented element to include in the WAP project xml Property Group?

[jagbarcelo]

@dianmsft, @TimMangan I also tried the process described in https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity but got stuck in the Create the package section. We are using Visual Studio too but the documentation was so lean and short that we couldn't find a way to pass that stage.

Then I ask for more information about it to the guys who made that documentation (see https://github.com/MicrosoftDocs/msix-docs/issues/333) and they replied:

This feature is currently not supported for Visual Studio. But we'll consider it in our backlog

... and back to square one... (sigh)

[florelis]

"You will still need to install the old certificate (recommended with timestamp) on the machine for the platform to install the package that was signed by the new certificate" in the document is being mis-understood by us and that the expired certificate does not need to be installed on end user systems.

@TimMangan It should not work without the expired certificate(*); and if it does that's a bug. If the signature is not trusted, then there isn't much difference with it not being signed as anybody could create a fake certificate and use it to sign.

(*) It can be any certificate in the certificate chain, it doesn't need to be yours specifically. For example, it can be the one from the CA root, which could still be valid.

The question becomes how to trick WAP Publishing in Visual Studio to include the /pb option when makemsix is run? Is there an underdocumented element to include in the WAP project xml Property Group?

@TimMangan @jagbarcelo Unfortunately, VS hasn't been updated to support this feature yet. Even if you are able to make VS pass the /pb option to makeappx, you will likely need to sign manually with signtool as VS would probably enforce that the manifest publisher must be the same as the cert subject.

I think a flow like this would work:

1. Build the package with VS but don't sign. This would produce the AppxManifest.xml from the Package.appxmanifest, place all the files in the correct location and other things like that.
2. Edit the package manually to add the artifacts and sign. This could probably be done in a postbuild task 2.1 Unpack with makeappx unpack 2.2 Re-pack with makeappx pack but passing the /pb option 2.3 Sign with signtool

Or if you can get VS to pass the /pb option you would be able to do

1. Build with VS with /pb but don't sign
2. Sign with signtool (in a postbuild task)

Windows Application Packaging projects are not my area of expertise, so the following may actually be very a bad idea and not officially supported but.... To make VS pass /pb, you could look into the Microsoft.AppxPackage.Targets file to try and find a property that you could set that would be passed to makeappx. On my machine this is on D:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppxPackage.Targets. In there I saw that the <MakeAppxPackage> task takes as input Parameters="$(CreatePackageMakeAppxParameters)". So it may be that you can set <CreatePackageMakeAppxParameters>/pb artifacts.txt</CreatePackageMakeAppxParameters> in your .wapproj file.

[jagbarcelo]

To make VS pass /pb, you could look into the Microsoft.AppxPackage.Targets file to try and find a property that you could set that would be passed to makeappx. On my machine this is on D:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppxPackage.Targets. In there I saw that the <MakeAppxPackage> task takes as input Parameters="$(CreatePackageMakeAppxParameters)". So it may be that you can set <CreatePackageMakeAppxParameters>/pb artifacts.txt</CreatePackageMakeAppxParameters> in your .wapproj file.

No luck with that. When we included <CreatePackageMakeAppxParameters>/pb artifacts.txt</CreatePackageMakeAppxParameters> within our PackageProject.wapproj file and tried to Publish, we receive this error:

It seems Visual Studio 2022 (Community at least) does not support the /pb option, not even when passed manually inside the .wapproj file.

I'm starting to lose all hope that this issue would ever be solved for real-world usable scenarios in a simple way, instead of a twisted cumbersome tweak using commands that cannot be reproduced/scripted/integrated in Visual Studio which is what we use.

We are forced to follow the least friction path and ask our users to uninstall, reboot and reinstall the app again.

[florelis]

Unknown command line option: "/pb"

That probably means that the version of makeappx you are using does not support this feature. It is available starting on build 22000. I imagine that VS uses an SDK with version matching your project's target platform, so if you are targeting something older than build 22000, you won't be able to use it.

[kapsiR]

We introduced a new feature that is currently in an Insider Build that tackles the issue of packages unable to update due to signing certificate changes. Here is the link to the documentation: https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity

From this document:

Starting in Windows Insider Preview Build 22000, an artifact will need to be created to show the relationship between the old certificate and the new certificate that is being used for signing.

@dianmsft @lechacon Does that mean we have to use the Windows 11 SDK or does that mean this feature is only supported on Windows 11? (The requirements section specifies only the SDK, but it's not clear to us)

Just to document our problems here too:

• CA change lead to different CN
• Legal business name change lead to different CN
• Changes in CA requirements lead to different CN

[kapsiR]

For anyone looking for the same (see the above question about requirements), I found an answer in the docs repo.

Thanks @marv51 for testing this!

TL;DR

It is definitely a runtime requirement. This publisher-bridge does not work on Windows 10 at all.

[myokeeh]

I'm just starting with code-signing and wondering if this is still an issue.

[jbennink]

Wow, this is discouraging. But I followed the steps at MSIX persistent identity and created the files, added the certificate etc. I am using VS2022 17.5.1 but get an error 0x80080218 - The published bridging artifact is invalid

I found this link that explained you should keep using the original CN in the appmanifest, which I had changed to the new one. After changing that it build. After fixing my update site SUCCESS it worked, updates happen automatically.

Wow, this is a very complex procedure to go through but at least it works, thank you for sorting this out. My new cert is good for 3 years so hopefully nothing else happens in the mean time :-)

[mikehearn]

@florelis We've been looking into this feature a bit more now, but it appears to be hard to use for a few interacting reasons (beyond the VS Studio issues which don't affect us because we don't use the native toolchain at all).

The problem is the decision to stop maintaining Windows 10. That's still most of the market share and given current trends, it will be many years until Windows 11 is the main version in use let alone having replaced 10. That means that using the publisher bridge effectively forks the packaging. From that moment on you need a separate MSIX+appinstaller update stream for Win10 vs Win11. The Win11 one must continue to express the old app identity and be signed with the new cert, but therefore can't be installed on Win10. The Win10 MSIX must be signed under the new non-expired identity, therefore it can't be used to upgrade anything. Users must uninstall and reinstall. Also users must be given the right package at install time depending on their OS version, and any code that relies on or uses the package identity needs to handle the fact that there may be >1 identity in use for the same app.

This generates enormous logistical complexity. Multiple sets of "independent" MSIX packages with their own update streams, needing to keep them separated, etc.

Now, if Win10 got backports of this feature the problems mostly go away. We could potentially detect users are not fully updated and tell them to apply OS updates in order to re-enable app updates. That's harder when the upgrade we're asking the user to apply is Win11, which isn't even available to all users. But we know from bitter experience that the MSIX team seem either to be prevented by internal rules or uninterested in maintaining the technology for Win10. Whatever the reason, Win10 has to be taken as fixed just as if it were shipped on a CD.

That constraint means we'll probably need to look at alternatives to the publisher bridge, like just forcing an uninstall+reinstall cycle any time the CN has changed. And longer term, look into moving away from MSIX (somehow - it's not like there are great alternatives). It has some wonderful features but the state of the tech in Win10 just isn't good enough, yet Win10 is the OS that matters most.

I realize you're a dev and don't directly influence these decisions but please do send this feedback up the chain. Package identity is a key part of the Windows platform strategy but devs can't adopt it when a basic part of the story doesn't work on Win10.