1506150 - MSI private properties missing correct values

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Adrian Florinescu [:aflorinescu]]

Attachment: screenshot_UAC_details.JPEG

[Description:]
When the MSI is executed without the silent argument, depending on the administrative privileges and UAC settings an UAC permission is required to continue installing. 

screenshot_UAC_details - details for the UAC permission window; (apologies for the quality)
screenshot_MSI_properties - MSI properties;  

-Publisher: Uknown - I would assume that is either because the test artifacts weren't oficially signed and/or the MSI was edited.
-0.0.0.0 -this corresponds with the MSI properties field: ProductVersion, not sure what we should have here.
-English(United States) - this corresponds with the MSI properties field: ProductLanguage - which is set in the MSIs to 0.
Testing with an MSI edited with a 10 value for the ProductLanguage would show Spanish(Spain, International Sort), so I would imagine that for each localized MSI, we would need to set the ProductLanguage to match the localization.

[Environment:]
Windows 10, Windows 7, Windows 8, Windows 8.1

Fx65 CI arefacts: 
win32 -de - https://queue.taskcluster.net/v1/task/F9fE80bDSZ2qxHzc6yKZcw/runs/0/artifacts/public/build/de/target.installer.msi
win32 - zh-CN - https://queue.taskcluster.net/v1/task/eIn2Vfn_SfGDZUdZA7Dg5A/runs/0/artifacts/public/build/zh-CN/target.installer.msi
win32 (deved) - de - https://queue.taskcluster.net/v1/task/cfrNyptBRgiFi5mtdOspYw/runs/0/artifacts/public/build/de/target.installer.msi
win32 (deved) - zh-CN - https://queue.taskcluster.net/v1/task/SDCa-6a-Ss2An5_R-ifDgQ/runs/0/artifacts/public/build/zh-CN/target.installer.msi
win64 - de - https://queue.taskcluster.net/v1/task/HejZ5jiYTcqNwya-jDy-2A/runs/0/artifacts/public/build/de/target.installer.msi
win64 - zh-CN - https://queue.taskcluster.net/v1/task/ZsX4mNxoQoWIGqj5sSFV3Q/runs/0/artifacts/public/build/zh-CN/target.installer.msi
win64 (deved) - de - https://queue.taskcluster.net/v1/task/bfYP-sDxSFuwpkJG6_abWw/runs/0/artifacts/public/build/de/target.installer.msi
win64 (deved) - zh-CN - https://queue.taskcluster.net/v1/task/QrqduTZ0T0ur0SGibMJDLA/runs/0/artifacts/public/build/zh-CN/target.installer.msi

Comment 1

[Adrian Florinescu [:aflorinescu]]

Attachment: screenshot_MSI_properties.jpg

Comment 2

[Justin Wood (:Callek)]

So, I've pointed adrian at a new .msi (with nightly signing, for win32 en-US) which resolves the unknown publisher issue, but I have no idea on the other mentioned issues, Matt thoughts?

https://queue.taskcluster.net/v1/task/Z7ztVQblRNaUN0-CMC9gKg/runs/0/artifacts/public/build/target.installer.msi

Comment 3

[Molly Howell (she/her) (mostly inactive)]

(In reply to Adrian Florinescu [:adrian_sv] from comment #0)
> -Publisher: Uknown - I would assume that is either because the test
> artifacts weren't oficially signed and/or the MSI was edited.

Yeah, as you and Callek figured out, this is caused by the untrusted certificate.

> -0.0.0.0 -this corresponds with the MSI properties field: ProductVersion,
> not sure what we should have here.

We aren't really able to represent our version strings as MSI versions because they don't fit that format. So rather than try to hack up some conversion, which would be confusing because it would lose information, I decided to leave it at 0 and include our version in the product name field.

> -English(United States) - this corresponds with the MSI properties field:
> ProductLanguage - which is set in the MSIs to 0.
> Testing with an MSI edited with a 10 value for the ProductLanguage would
> show Spanish(Spain, International Sort), so I would imagine that for each
> localized MSI, we would need to set the ProductLanguage to match the
> localization.

I didn't think 0 would render as en-US; it's supposed to represent the neutral locale. You have to fill in the ProductLanguage field with a Windows numeric LANGID, and I didn't think it would be worth trying to convert our AB_CD strings over to that; maybe there's an easy way to do that that I don't know about.

Comment 4

[Kim Moir [:kmoir] ET]

Triaging. Callek is there someone this can be assigned who is actively working on the MSI project or could someone from the build team be of assistance?

Comment 5

[Justin Wood (:Callek)]

I think this will rely on :mhowell or someone to say what we *want* here and then someone like mhowell to triage as a product owner and rope in me or build team as necessary.

I'm suspecting that fixing this would be (likely) outside the scope of releng involvement, unless of course I need to modify the taskgraph and mach repackage command to support it.

Comment 6

[Molly Howell (she/her) (mostly inactive)]

(In reply to Justin Wood (:Callek) from comment #5)
> I'm suspecting that fixing this would be (likely) outside the scope of
> releng involvement, unless of course I need to modify the taskgraph and mach
> repackage command to support it.

I'm not sure where to put the fix other than in repackage_msi; the locale string needs to be converted to a Windows locale number, and I don't know where else it makes sense to put that logic.

I also don't have a sense for how hard that conversion is to do; there could be a nice Python library somewhere that already does a good enough job, or it could just be an impossible problem, I have no idea. If it's too hard, then I don't think it's worth fixing.

Comment 7

[Justin Wood (:Callek)]

(In reply to Matt Howell (he/him) [:mhowell] from comment #6)
> (In reply to Justin Wood (:Callek) from comment #5)
> > I'm suspecting that fixing this would be (likely) outside the scope of
> > releng involvement, unless of course I need to modify the taskgraph and mach
> > repackage command to support it.
> 
> I'm not sure where to put the fix other than in repackage_msi; the locale
> string needs to be converted to a Windows locale number, and I don't know
> where else it makes sense to put that logic.
> 
> I also don't have a sense for how hard that conversion is to do; there could
> be a nice Python library somewhere that already does a good enough job, or
> it could just be an impossible problem, I have no idea. If it's too hard,
> then I don't think it's worth fixing.

Let me rope in :Pike here then, since I don't know enough about l10n-world in that detail to have a good idea on implementation details.

Pike, tl;dr do you know of any meaningful way to map LANGID windows locale) integer to our locale strings, in a way that we can have at most one LANGID per each of our own locales, and never 0?

Alternatively any other suggestion on implementation here?

Comment 8

[Axel Hecht [:Pike]]

I don't know anything, and I also struggle to make sense of https://docs.microsoft.com/windows/desktop/Intl/language-identifier-constants-and-strings, if that's what we're talking about.

In a single-locale msi, we might just be OK with LANG_NEUTRAL and a localized string, though.

Comment 9

[Justin Wood (:Callek)]

I also did some google searching and tried to make sense of this, I can't come up with fruit right now. :Mhowell is this enough information to go on to make a determination as to if we should wontfix.

If not, what more do you need, and any idea on who can provide it? Since I have no idea what we would do or where to get the mapping from.

Comment 10

[Molly Howell (she/her) (mostly inactive)]

It sounds like a WONTFIX to me. If there isn't an easy way to get a LANGID mapping that we're confident in (I also can't find anything readily available), then I don't think it's worth the effort to try to generate one.

Comment 11

[Justin Wood (:Callek)]

I agree that it sounds like ROI on this work isn't worthwhile based on what we know today.

Comment 14

[Olav Birkeland]

We aren't really able to represent our version strings as MSI versions because they don't fit that format. So rather than try to hack up some conversion, which would be confusing because it would lose information, I decided to leave it at 0 and include our version in the product name field.

How doesn't "65.0.2" (current stable) fit that field? Just add a zero at the end? "65.0.2.0".

By leaving it to zero, you make it harder for us to maintain MSI installation through Intune, SCCM etc. if we're not able to compare version number. I don't see why you can't comply with this standard MSI property.

Comment 15

[Molly Howell (she/her) (mostly inactive)]

Release and ESR version numbers are not the problem, the problem is every other channel (beta, developer edition, and nightly), where the version string includes a version number, and then a letter, and then another number. There is no way to map that onto the Microsoft version number scheme without leaving out information, causing confusion, or both.

Comment 16

[Olav Birkeland]

(In reply to Matt Howell (he/him) [:mhowell] from comment #15)

Release and ESR version numbers are not the problem, the problem is every other channel (beta, developer edition, and nightly), where the version string includes a version number, and then a letter, and then another number. There is no way to map that onto the Microsoft version number scheme without leaving out information, causing confusion, or both.

Sorry if this is answered already, but why not include version info to Release and ESR only then?

Comment 17

[Molly Howell (she/her) (mostly inactive)]

(In reply to Olav Birkeland from comment #16)

Sorry if this is answered already, but why not include version info to Release and ESR only then?

I hadn't thought of that, and it does seem like a good idea. Justin, do you think it would be possible to have the MSI repack fill in the version number for just release and ESR (the channels where the version number is trivial to map to an MSI version)? It would take care of a huge majority of the MSI version number issues in practice, I think.

Comment 18

[Justin Wood (:Callek)]

That should be possible, I'm not sure on what timeline I can commit to doing it though. I don't think it will be necessarily hard either.

It does add a slight vector of potential divergence from beta to release which could hide a bug or two of course that only gets uncovered on release day, though I don't think that is a big worry in this case.

Comment 19

[Molly Howell (she/her) (mostly inactive)]

Okay, thanks. I'll file a separate bug.