MSI package issues

[GitMensch]

At least in VSCodium-x64-updates-disabled-1.60.0.msi the language is set to/detected as "Chinese (Traditional, Taiwan)". So "ignore language" option needs to be set in software deployment systems that detect the language and compare it to Windows language.

Originally posted by @bluikko in https://github.com/VSCodium/vscodium/issues/106#issuecomment-915814070

and mostly cosmetic:

Both convert and wix (other than Inno) can use PNGs, can you check for an adjustment here to favor PNG over bmp?

Originally posted by @GitMensch in https://github.com/VSCodium/vscodium/pull/827#discussion_r704970643

[daiyam]

zh-tw is the last language added so it seems to become the default.

[GitMensch]

I bet there's a configuration option to explicit set it (or best: activate "try to find the one matching the OS"), I suggest we see if someone knows of that and otherwise check the wix-docs in some days.

[daiyam]

@daiyam In my test, the language were English. Maybe it's something about the deployment systems...

[bluikko]

Yes, it is about deployment systems. This example is from Active Directory Software Installation - the most dumbest one. If run manually I guess it could just install the one matching the OS language but AD SI seems to always just pick one language and unless the language is set to be ignored it won't install anything (I don't have a Chinese OS available, I guess that would install OK).

[daiyam]

@bluikko Do you know what we will have to improve that?

[bluikko]

@bluikko Do you know what we will have to improve that?

I do not know. I can test if someone can build an MSI following your idea about the last language added being the default.

[GitMensch]

I'm quite sure that this will work - but that it won't be the correct solution. There has to be a configuration option for that...

[bluikko]

I'm quite sure that this will work - but that it won't be the correct solution. There has to be a configuration option for that...

I suspect it is a peculiarity of Microsoft's AD SI.

If the MSI is installed manually the language will be (?) chosen to match the OS (as @daiyam reported in https://github.com/VSCodium/vscodium/issues/830#issuecomment-915839346).

AD SI will just take the first language it sees (or some configured language) and installation is not done if the OS language is different.

But, if "ignore language" option is selected in AD SI, then the MSI is installed and installed language is correct English (for English OS).

AD SI is the most basic deployment system, frankly full of pitfalls and problems - but it is the built-in free solution Microsoft provides so many are stuck with it.

Edit: or maybe there is an option for that in the MSI/WiX. But I have seen this same issue with a few other packages - namely stuff from VMware.

[InterLinked1]

I can confirm that I just tried adding this as well and it defaults to Chinese - Traditional (Tawian). Otherwise, though, MSI seems to work great!

[alexhass]

The language is auto-detected in this installer. That is normal behaviour and nothing wrong in the MSI. Honestly I was not aware that an undetected language ends with chinese... that sounds like a wrong choice to me, too. I would default to english. If this is caused by the order, than this can be easily changed. Can you try change the Languages field as you can see in below screenshot and verify if moving 1033 to the end of the string will default to english than, please?

It is also normal that you need to enable ignore language in AD deployment if the MSI is mulitlingual.

This can be solved by removing all languages from the language field - except 1033 - english. It is also an option that the project builds an installer for English only. Personally I like this and it may be a better start. Simply comment out the "CALL BuildSetupTranslationTransform.cmd xxx" and we have an english installer only.

[alexhass]

Please see LibeOffice Documentation how to deploy via AD. You need Orca or InstEd and you can disable all languages except English 1033.

https://wiki.documentfoundation.org/Deployment_and_Migration

Managed software deployment This is the recommended method as you can centrally manage which version of LibO is installed on various machines in Active Directory as well as centrally deploy upgrades just by adding a newer package to the GPO.

1. Download the installer for the version of LibO you want to deploy.
2. Open the MSI file in ORCA or InstEd. (See the section on MSI editing for download links.)
3. Go to View ▸ Summary Information... in ORCA or Tables ▸ Summary Info... in InstEd.
4. Remove some of the language codes listed in the Languages field, making sure to keep at least the one(s) you need. http://www.science.co.il/language/locale-codes.asp (This is required to avoid an error when adding the package to the GPO.)
5. Save the MSI to a network location where all machine accounts have Read access.

Here is a screenshot:

[alexhass]

Has the project the ability to sign the MSI?

[GitMensch]

The project has the ability (the worker have signtool and the password can be used as secure token (if it isn't set then no signing would happen). But so far no one showed up that sponsored a digital code certificate we can use (issue concerning code-signing: #174).

[bluikko]

What would be the cost for the certificate? A quick search shows some vendors ask $300-$500 for a non-EV code signing certificate. Does the project have the ability to accept donations if I can get the company to donate that money? I can't promise anything at this point but I can try at least.

[GitMensch]

@stripedpajamas "Does the project have the ability to accept donations [...]?" I don't know. But something that may work much easier is ask the vendors directly to create the certificate for the project an pay in in behalf of it as a company. https://comodosslstore.com/codesigning.aspx would be 319 USD for one year and 798 for three years.

There's an option for signing as part of a CI action "for free" at https://about.signpath.io/open-source - @daiyam @stripedpajamas would this be reasonable to use?

[bluikko]

https://shop.globalsign.com/en/code-signing is $289 (1 year) / $599 (3 years) - if a paid certificate is acquired it pretty much does not matter where it's from and the cheapest could be OK? I'd expect any CA selling code signing certificates to be pretty universally accepted?

[GitMensch]

I'd expect any CA selling code signing certificates to be pretty universally accepted?

Not completely, it depends where their root certificate is installed (some older/newer Windows versions may not have them installed).

the cheapest could be OK.

Could be, depends on the need. To not have Windows Smart Screen be shown at all - like the VSCode installer - you'd need an "extended validation" one, but I'd have to check if you can put this into a CI pipeline.

[github-actions[bot]]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment, and we'll keep it open. If you have any new additional information, please include it with your comment!

[daiyam]

Let's keep it active.

[GitMensch]

We should not track the certificate things here as we have a different issue for that.

@daiyam

zh-tw is the last language added so it seems to become the default.

Can we add an English language last to possibly work around that?

Both convert and wix (other than Inno) can use PNGs, can you check for an adjustment here to favor PNG over bmp?

Is there a reason to keep the bmp files in the repo?

[bluikko]

Can we add an English language last to possibly work around that?

It would be a great improvement IMHO to set the language 1033 (en-us? or would it be specified as 1033? I'm sure you know better) as last: it would mean the majority of the users (who likely have the 1033 language) would not need to specifically change something to install the package in cases where package language matters.
I personally at least often forget to set the "ignore package language" flag when adding a new version and then nobody gets the package until I remove&readd with the flag set - this option is something that was not mentioned in https://github.com/VSCodium/vscodium/issues/830#issuecomment-916726209 and the "disable languages" workaround is needed only in special cases (cases where some data in the MSI was too large IIRC).

I have also seen MSI packages with "unspecified" as the language - but I do not know what this means in practice or how that's achieved; or indeed if it's relevant here at all when languages are included in the MSI.

Edit: I hadn't noticed this one:

but I'd have to check if you can put this into a CI pipeline

I thought EV certificates needed to be stored on HSMs but at least one vendor seemed to refer to "can be stored on HSM". Perhaps the easiest way would be to access through cloud service APIs, one example would be https://www.ssl.com/how-to/cloud-code-signing-integration-with-gitlab-ci

[daiyam]

@GitMensch I've contacted SignPath. So it seems that we can the windows binaries to be signed by them but it would require to have the build process to AppVeyor because they have an automatic vetting process for the binary artifacts from OSS projects.

[GitMensch]

AppVeyor can be really slow; wouldn't integration with GitHub actions be useful for them, too? If they don't - do you have an idea how long the run may take on Appveyor?

Note: If this helps "a lot" I could try to setup a appveyor configuration for the window builds (would be x86 x64 and arm64 via msys2).

[daiyam]

wouldn't integration with GitHub actions be useful for them, too?

I did ask.

If they don't - do you have an idea how long the run may take on Appveyor?

No idea. I don't know AppVeyor. So any help would be welcome if we go that route.

[GitMensch]

Will do, so assigned to me until ready, then will assign it to you afterwards.