Jun 28 2021 01:16 PM
In the past I have complained about the method by which the subject field of the certificate (aka Publisher) is hashed and used in the Package Full Name as I suspected it would cause problems for Microsoft partners that create software down the road. And now I have run into the problem full tilt.
We are 3 years in so my code signing certificate has now expired. After 2 months of effort, I still have not found a CA that can actually produce a new certificate with the same subject field. And this is without my company being bought or renamed in the interim (which others will face). The latest issue is that the CA decided to remove postal information from the field on all new certs.
This changes the SHA256 hash and the uuencoded PublisherID that is used to make up the Package Full Name. And that means my existing customers cannot upgrade their current packages. Removal and Install (with loss of configuration) is required and that is not acceptable. I might be the first to face this problem, but by no means will I be the last unless the upgrade process is adapted.
AppInstaller recognition of a package as an upgrade of an existing package should not depend on this mechanism.
Jul 07 2021 09:35 AM
Jul 07 2021 09:49 AM
Nov 12 2021 07:24 AM
Nov 12 2021 01:48 PM
@Dian Hartono Well I had intend to mean the Registry.dat as that's one of the places they are stored when a package is captured by the Microsoft MSIX packaging tool (see attached image). ANother copy is also stored in the User.dat file, so whichever source the installer uses I mean that one.
By the way, it would be nice to know if one of those is a mistake and need not be in the package. My tooling makes duplicate changes in both of those files when editing the package.
Jan 30 2024 09:59 AM