mirror of
https://github.com/VSCodium/vscodium.git
synced 2026-04-09 14:14:16 -05:00
MSI package issues #957
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @GitMensch on GitHub.
Originally assigned to: @GitMensch on GitHub.
Originally posted by @bluikko in https://github.com/VSCodium/vscodium/issues/106#issuecomment-915814070
and mostly cosmetic:
Originally posted by @GitMensch in https://github.com/VSCodium/vscodium/pull/827#discussion_r704970643
@bluikko commented on GitHub:
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).
@GitMensch commented on GitHub:
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 commented on GitHub:
zh-twis the last language added so it seems to become the default.@daiyam commented on GitHub:
@bluikko Do you know what we will have to improve that?
@daiyam commented on GitHub:
@daiyam In my test, the language were English. Maybe it's something about the deployment systems...
@bluikko commented on GitHub:
I do not know. I can test if someone can build an MSI following your idea about the last language added being the default.
@alexhass commented on GitHub:
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.
@bluikko commented on GitHub:
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 commented on GitHub:
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!
@GitMensch commented on GitHub:
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...
@alexhass commented on GitHub:
Has the project the ability to sign the MSI?
@GitMensch commented on GitHub:
@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 commented on GitHub:
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.
@alexhass commented on GitHub:
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
Here is a screenshot:
@GitMensch commented on GitHub:
The project has the ability (the worker have
signtooland 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 commented on GitHub:
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?
@daiyam commented on GitHub:
Let's keep it active.
@GitMensch commented on GitHub:
We should not track the certificate things here as we have a different issue for that.
@daiyam
Can we add an English language last to possibly work around that?
Is there a reason to keep the bmp files in the repo?
@GitMensch commented on GitHub:
Not completely, it depends where their root certificate is installed (some older/newer Windows versions may not have them installed).
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] commented on GitHub:
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!
@GitMensch commented on GitHub:
Will do, so assigned to me until ready, then will assign it to you afterwards.
@GitMensch commented on GitHub:
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).
@bluikko commented on GitHub:
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:
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 commented on GitHub:
@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.
@daiyam commented on GitHub:
I did ask.
No idea. I don't know AppVeyor. So any help would be welcome if we go that route.