Chrome/Chromium - Installation is not systemwide

[Golffies]

Describe the bug
Winutil installs Chrome or Chromium for the single user from which Winutil was launched; Chrome or Chromium are not installed systemwide and are therefore not accessible to other users.

To Reproduce
Steps to reproduce the behavior:

1. Start PowerShell with administrative rights.
2. Launch Winutil with the command irm https://christitus.com/win | iex.
3. Check the box in front of the Chrome/Chromium application name.
4. Click on the "Install Selected" button.
5. Exit Winutil.
6. In the start menu, click on the Chrome/Chromium application icon, and use the browser as usual.
7. Change user and log on to the account of a user without administrative rights.
8. In the start menu, look for the Chrome application icon, but you can't find it.
9. Run a search on the hard disk for this user; the search returns no results.

Expected behavior
In the start menu of other users, the Chrome/Chromium application should be accessible and launchable.

Screenshots
N/A

Additional context
Winutil installs the Firefox browser systemwide, enabling all users to use it. The same is true of other applications installed by Winutil.

[ruxunderscore]

I can look more into this and try to find a better solution. Currently, machine scope for installs was disabled as it was preventing the installs of non-UWP apps entirely (A bug with winget, itself.).

[SkylerWallace]

This is an interesting topic LOL

Winget uses a hash-validation check to ensure security. When Winget downloads from a URL, it checks what is downloaded to an internal hash to verify the file that is downloaded matches what is in Winget's database. The issue with this security check is that some URLs are 'vanity URLs'.

Winget has been using the following URL for Chrome for a long time:
https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi

Notice how there is no version number for Chrome anywhere in that URL? This is a static URL that always downloads the latest version of Google Chrome. So whenever Google updates Chrome, Winget's hash validation will fail until somebody updates the package manifest. This has resulted in Google Chrome frequently failing to install via Winget.

Some time ago, somebody discovered a new URL to download Google Chrome:
https://dl.google.com/release2/chrome/adectmwfwjgwtszkubqhiqc33nta_122.0.6261.70/122.0.6261.70_chrome_installer.exe

Notice how that URL has a version number in it. This URL always downloads that specific version of Chrome which means the hash-validation check will no longer fail anytime Google publishes a new version of Google Chrome.

Somebody published a package manifest update to Winget and for some reason it was approved...
microsoft/winget-pkgs@c84374a

The issue is that this new package manifest only installs for the current user instead of system-wide! Chaos ensued.

Thankfully this was recently reverted to using the old vanity URL which returns the occasional hash-validation failure but at least it installs system-wide which is what 99% of people likely want. Can't find the specific commit where this was fixed but it happened within the last week.

TLDR Issue isn't WinUtil, issue is Winget. This issue has self-resolved already, this issue can be closed.

[ruxunderscore]

This is an interesting topic LOL

Winget uses a hash-validation check to ensure security. When Winget downloads from a URL, it checks what is downloaded to an internal hash to verify the file that is downloaded matches what is in Winget's database. The issue with this security check is that some URLs are 'vanity URLs'.

Winget has been using the following URL for Chrome for a long time: https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi

Notice how there is no version number for Chrome anywhere in that URL? This is a static URL that always downloads the latest version of Google Chrome. So whenever Google updates Chrome, Winget's hash validation will fail until somebody updates the package manifest. This has resulted in Google Chrome frequently failing to install via Winget.

Some time ago, somebody discovered a new URL to download Google Chrome: https://dl.google.com/release2/chrome/adectmwfwjgwtszkubqhiqc33nta_122.0.6261.70/122.0.6261.70_chrome_installer.exe

Notice how that URL has a version number in it. This URL always downloads that specific version of Chrome which means the hash-validation check will no longer fail anytime Google publishes a new version of Google Chrome.

Somebody published a package manifest update to Winget and for some reason it was approved... microsoft/winget-pkgs@c84374a

The issue is that this new package manifest only installs for the current user instead of system-wide! Chaos ensued.

Thankfully this was recently reverted to using the old vanity URL which returns the occasional hash-validation failure but at least it installs system-wide which is what 99% of people likely want. Can't find the specific commit where this was fixed but it happened within the last week.

TLDR Issue isn't WinUtil, issue is Winget. This issue has self-resolved already, this issue can be closed.

Interesting. I missed that issue. I know there was also an issue as I had mentioned above and believed that to be the issue. I had to work around scopes with my "fix" as the scope flag fully depends on package being installed on how it handles the install. Chrome doesn't respond to "user" scope at all from my testing, while Paint.NET doesn't respond to "machine" scope or "user", but does respond to "all" scope.

[Golffies]

These explanations about Chrome are interesting. In my bug report, I observed the same problem when installing Chromium. However, the repository is not the same as for Chrome. Why is the installation of Chromium also limited to the current user?

As far as Chrome is concerned, are we to understand that Winutil doesn't currently guarantee that the package installed is the original, unaltered package, because it can't check the checksum? At the very least, a clear message should be sent to the user so that they are aware of this.

[ChrisTitusTech]

This should work with #1856