SHA-256 collisions between different installer URLs, for different architectures, are not flagged as a manifest bug?

[R-Adrian]

Brief description of your issue

winget currently does not flag as a manifest warning /error when it encounters the same SHA-256 checksum for installers for different cpu architectures?

This can lead to 64-bit programs being "upgraded" to 32-bit versions.

Steps to reproduce

have something like this in a package manifest: (same checksum, different installer URLs, different architectures)

Installers:
- Architecture: x64
  InstallerUrl: https://edge.dropboxstatic.com/dbx-releng/client/Dropbox%20165.4.4300%20Offline%20Installer.exe
  InstallerSha256: 6AFE5324E7D2C18D565B2E5BBD98853C8CCD44DA3F0DCE03608B54DBBBCA6D1F
- Architecture: x86
  InstallerUrl: https://edge.dropboxstatic.com/dbx-releng/client/Dropbox%20165.4.4300%20Offline%20Installer.x86.exe
  InstallerSha256: 6AFE5324E7D2C18D565B2E5BBD98853C8CCD44DA3F0DCE03608B54DBBBCA6D1F

also, see issue https://github.com/microsoft/winget-pkgs/issues/93678

Expected behavior

at least show a warning message in the console about the same checksum being present in the manifest file, but for different CPU architectures.

Actual behavior

because of the manifest specifying the same installer for different architectures, winget behaves "normally" and "upgrades" a 64-bit program to a 32-bit version. This might be "normal" for some programs that detect the architecture directly in the installer, but not all of them do. Those that can detect this should have a warning-suppression flag in the manifest for it.

Case in point: the Dropbox installer from the manifest quoted above will happily "upgrade" a 64-bit version to a 32-bit one, because the winget manifest specifies the same file for both x86 and x64 architectures.

Environment

> winget --info
Windows Package Manager (Preview) v1.5.101-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.2486
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.101.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

[Trenly]

There are many times that publishers do use the same installer for x86 and x64, relying on the installer itself to perform the appropriate steps for the architecture, so warning just because the hashes are the same seems excessive to me.

However, I do think that additional validation could be added to the winget-pkgs pipelines to detect manifest errors like this. Since each architecture is validated independently, I can imagine it would be possible for the agent to check if the installer modified Program Files or Program Files (x86) to validate architecture, or even AppData for a user scoped application.

[R-Adrian]

There are many times that publishers do use the same installer for x86 and x64, relying on the installer itself to perform the appropriate steps for the architecture, so warning just because the hashes are the same seems excessive to me.

then it should not be flagged as a problem if it is the EXACT same URL specified for both x64 and x86. (not sure about this though, maybe still show a simple notification text about it, in case it is a manifest bug? In my opinion there still should be a flag in the winget manifest that specifies that the installer is a multiple-architecture installer)

However, in the Dropbox case above there are different URLs specified for different platforms, but they result in the download of the same file.

I can imagine it would be possible for the agent to check if the installer modified Program Files or Program Files (x86) to validate architecture, or even AppData for a user scoped application.

In the case of Dropbox this would be a problem because their x64 installer puts the files under the same C:\Program Files (x86)\Dropbox\ folder as the x86 installer - seems they hard-coded the install path to be the same for both x64 and x86

And Dropbox is not the only program that puts 64-bit executables under the C:\Program Files (x86) folder, Google also does the same thing with Chrome. C:\Program Files (x86)\Google\Update\1.3.36.152\GoogleCrashHandler64.exe C:\Program Files (x86)\Google\Chrome\Application\chrome.exe Are 64-bit programs on my system.

[stephengillie]

Please note that x86 packages are validated on a 32-bit OS. while x64 packages are validated on a 64-bit OS. So these installers seem to support multiple architectures.

Switching architectures is sometimes seen during updates for several reasons, including misdetection the installed architecture at various levels, having both architectures installed side by side, installer flavor (EXE/MSI/PWA) changing, or the uninstaller cleaning up any architecture information from the previous install.

Can you run winget install Dropbox.Dropbox --verbose-logs and post the logs here? The log location is specified in winget --info

Similar situations:

• https://github.com/microsoft/winget-pkgs/issues/88000
• https://github.com/microsoft/winget-pkgs/issues/67506

[R-Adrian]

the Dropbox exe installer that was linked in that "Steps to reproduce" manifest sample from the first message is a 32-bit -only installer, it has no other files for 64-bit systems. Even on 64-bit systems it will install the 32-bit version.

However, since i opened the winget-cli issue here, the winget issue for the package itself, and its manifest was fixed: https://github.com/microsoft/winget-pkgs/pull/93889 So running winget install now will install the correct 64-bit Dropbox version.

What i was puzzled about was why would winget even allow a potentially wrong-architecture installer to be listed, multiple times even, without showing any warnings in the console about the duplicate checksums.

Please note that i do not have another machine to sacrifice just for the sake of that experiment of reinstalling Dropbox from scratch... and if i mess the current installation i would have to wipe /troubleshoot and then re-synchronize quite a few gigabytes of personal files - had to do that a few years ago when a drive crashed and it was not funny, the resync / recovery was a pain in the rear because Dropbox kept creating duplicates / conflicting copies and i had to examine each of them.

Also, running that winget install command on my system does not produce much related to Dropbox in the verbose logs from %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir, probably because the correct x64 version is already installed. Winget displays this message instead of running the actual upgrade.

C:\WINDOWS\system32>winget install Dropbox.Dropbox --verbose-logs
Found an existing package already installed. Trying to upgrade the installed package...
No applicable upgrade found.

C:\WINDOWS\system32>winget show Dropbox.Dropbox
Found Dropbox [Dropbox.Dropbox]
Version: 165.4.4300
Publisher: Dropbox, Inc.
Publisher Url: https://www.dropbox.com
Publisher Support Url: https://help.dropbox.com
Author: Dropbox, Inc.
Moniker: dropbox
Description: Organize all your team's content, tune out distractions, and get everyone coordinated with the world's first smart workspace.
Homepage: https://www.dropbox.com
License: Combined GPLv2 and proprietary software
License Url: https://www.dropbox.com/terms
Privacy Url: https://www.dropbox.com/privacy
Copyright: Copyright (c) Dropbox, Inc.
Copyright Url: https://www.dropbox.com/terms
Tags:
  cloud
  dropbox
  files
  online
  pictures
  storage
Installer:
  Installer Type: nullsoft
  Installer Url: https://edge.dropboxstatic.com/dbx-releng/client/Dropbox%20165.4.4300%20Offline%20Installer.x64.exe
  Installer SHA256: bfcebb9f521514b39abce00ffdc6b6fe3d41717a104efffd21092641a74633b8
  Release Date: 2023-01-12

[Masamune3210]

If you need a 32-bit machine, just make a 32-bit VM. It doesn't need to be particularly performant, just enough to do whatever you need to test

[R-Adrian]

If you need a 32-bit machine, just make a 32-bit VM. It doesn't need to be particularly performant, just enough to do whatever you need to test

a 32-bit machine is not the problem here, we already know that the installer in the 'steps to reproduce' sample is a valid x86 installer.

The problem that happens here is that the installer there is an exclusive x86-only installer that was listed 2-times in the manifest file, once for x64 and once for x86 and the azure-pipelines checks did not raise any warning flags about the SHA-256 checksum collision between the two separately-specified architectures or that it is a 32-bit only installer when the installed application that it is supposed to upgrade is already installed as a 64-bit binary: https://github.com/microsoft/winget-pkgs/pull/93622