infrastructure/codesign
1
1
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

UAC shows unknown .msi filenames (such as "d5b9f.msi") during installation and uninstallation #1

New Issue
Closed
opened 2024-09-04 23:33:14 +02:00 by xan2622 · 11 comments
xan2622 commented 2024-09-04 23:33:14 +02:00
Copy Link

tltr: The UAC requests confirmation to install "unknown" .msi files (such as "d5b9f.msi") and also shows a slightly different .msi file during uninstallation.

Broken: version: 4.2.1 LTS, 4.1.1, 2.93.18, 2.82, 2.81, 2.80, 2.79b
Worked: 2.65a

After a fresh installation of Windows 11 Pro (and its updates) in a vmware virtual machine, I wanted to check something related to the Blender uninstallation process, so:

  • I manually downloaded blender-4.2.1-windows-x64.msi from www.blender.org/download/

  • I compared the SHA256 checksum from https://download.blender.org/release/Blender4.2/ to the one that I just downloaded (both matched).

  • I ran the Blender 4.2.1 installer

  • But during the installation, another .msi file requested to be installed: "cb163.msi" (the installation got suspended until I accepted to install it as well).
    When I clicked on the V icon to show details about the file, it seemed legit, coming from the Blender Foundation.

Once Blender was installed (I didn't expect it to be launchable: no GPU in this virtual machine, obviously), I uninstalled it right away (that was the purpose of my test).
And at this moment, the User Account Control asked me to allow modifications from "cb165.msi" (a slightly different filename than the one I installed before).
I proceeded and Blender got uninstalled.

I repeated these steps several times (several installations and uninstallations) with the same .msi installer and each time, the .msi files were different.
20fff4c4.msi, 130871.msi, efe03.msi, efe04.msi, efe05.msi, efe06.msi, 189083.msi ...

Another weirdness: each time during the uninstallation process, the filename was different than the one that requested to be installed during the Blender installation.
189083.msi (installation) <> 189085.msi (uninstallation)
d5b9d.msi (installation) <> d5b9f.msi (uninstallation)
4e05a.msi (installation) <> 4e05c.msi (uninstallation)

For Blender 2.65a, the installer "behaved" like one would expect: the file shown during the installation was the same as the downloaded file (blender-2.65a-windows64.exe) and the uninstaller's filename looked normal (uninstall.exe).
b265a: C:\Users\user01\Downloads\blender-2.65a-windows64.exe <> C:\Program Files\Blender Foundation\Blender\uninstall.exe

For Blender 2.79a, the UAC asked if I really wanted to install "blender-2.79b-windows64.msi" but when I uninstalled it, the UAC showed "bf7112.msi".
b279b: C:\Users\user01\Downloads\blender-2.79b-windows64.msi <> C:\Windows\Installer\bf7112.msi

Other tests:
b280: C:\Users\user01\Downloads\blender-2.80-windows64.msi <> C:\Windows\Installer\b016ed.msi - bf50d2.msi - ...
b281: C:\Users\user01\Downloads\blender-2.81-windows64.msi <> C:\Windows\Installer\b0281d.msi - bf6202.msi - ...
b282: C:\Users\user01\Downloads\blender-2.82-windows64.msi <> C:\Windows\Installer\bf3190.msi - bf4131.msi - ...
b411: C:\Users\user01\Downloads\4e05a.msi <> C:\Windows\Installer\4e05c.msi
b421: C:\Users\user01\Downloads\189083.msi <> C:\Windows\Installer\189085.msi

Note that if you browse C:\Windows\Installer\ you can see the .msi files being temporarily placed there.

See also: https://stackoverflow.com/questions/6863137/odd-program-name-when-installing-signed-msi-installer

Looks like a signtool issue.. hence the reason why I posted this bug report here (sorry if this is not the correct place).

**tltr:** The UAC requests confirmation to install "unknown" .msi files (such as "d5b9f.msi") and also shows a slightly different .msi file during uninstallation. --- Broken: version: 4.2.1 LTS, 4.1.1, 2.93.18, 2.82, 2.81, 2.80, 2.79b Worked: 2.65a After a fresh installation of Windows 11 Pro (and its updates) in a vmware virtual machine, I wanted to check something related to the Blender uninstallation process, so: - I manually downloaded _blender-4.2.1-windows-x64.msi_ from [www.blender.org/download/](https://www.blender.org/download/) - I compared the SHA256 checksum from https://download.blender.org/release/Blender4.2/ to the one that I just downloaded (both matched). - I ran the Blender 4.2.1 installer - But during the installation, another .msi file requested to be installed: "cb163.msi" (the installation got suspended until I accepted to install it as well). When I clicked on the V icon to show details about the file, it seemed legit, coming from the Blender Foundation. Once Blender was installed (I didn't expect it to be launchable: no GPU in this virtual machine, obviously), I uninstalled it right away (that was the purpose of my test). And at this moment, the User Account Control asked me to allow modifications from "cb165.msi" (a slightly different filename than the one I installed before). I proceeded and Blender got uninstalled. I repeated these steps several times (several installations and uninstallations) with the same .msi installer and each time, the .msi files were different. 20fff4c4.msi, 130871.msi, efe03.msi, efe04.msi, efe05.msi, efe06.msi, 189083.msi ... Another weirdness: each time during the uninstallation process, the filename was different than the one that requested to be installed during the Blender installation. 189083.msi (installation) <> 189085.msi (uninstallation) d5b9d.msi (installation) <> d5b9f.msi (uninstallation) 4e05a.msi (installation) <> 4e05c.msi (uninstallation) For Blender 2.65a, the installer "behaved" like one would expect: the file shown during the installation was the same as the downloaded file (blender-2.65a-windows64.exe) and the uninstaller's filename looked normal (uninstall.exe). b265a: C:\Users\user01\Downloads\blender-2.65a-windows64.exe <> C:\Program Files\Blender Foundation\Blender\uninstall.exe For Blender 2.79a, the UAC asked if I really wanted to install "blender-2.79b-windows64.msi" but when I uninstalled it, the UAC showed "bf7112.msi". b279b: C:\Users\user01\Downloads\blender-2.79b-windows64.msi <> C:\Windows\Installer\bf7112.msi Other tests: b280: C:\Users\user01\Downloads\blender-2.80-windows64.msi <> C:\Windows\Installer\b016ed.msi - bf50d2.msi - ... b281: C:\Users\user01\Downloads\blender-2.81-windows64.msi <> C:\Windows\Installer\b0281d.msi - bf6202.msi - ... b282: C:\Users\user01\Downloads\blender-2.82-windows64.msi <> C:\Windows\Installer\bf3190.msi - bf4131.msi - ... b411: C:\Users\user01\Downloads\4e05a.msi <> C:\Windows\Installer\4e05c.msi b421: C:\Users\user01\Downloads\189083.msi <> C:\Windows\Installer\189085.msi Note that if you browse C:\Windows\Installer\ you can see the .msi files being temporarily placed there. See also: https://stackoverflow.com/questions/6863137/odd-program-name-when-installing-signed-msi-installer Looks like a signtool issue.. hence the reason why I posted this bug report here (sorry if this is not the correct place).
Sergey Sharybin commented 2024-09-05 11:28:50 +02:00
Owner
Copy Link

I'de tried using /d parameter, but it does not seem the have affected on anything. A test msi can be found at https://download.blender.org/ftp/sergey/attic/blender-4.2.1-windows-x64-test.msi (sha256 f170ed5d9a1b979c219b680758a0c8062ad9013ad542f3f4306160e16e67a787). The prompt during installation still showed a temporary msi name.

It is something I remember looking into with Ray a while ago, and from my memories it was more something intrinsic to the way how cpack generates the installer. Might be wrong though. Will point him to this task.

I'de tried using `/d` parameter, but it does not seem the have affected on anything. A test msi can be found at https://download.blender.org/ftp/sergey/attic/blender-4.2.1-windows-x64-test.msi (sha256 f170ed5d9a1b979c219b680758a0c8062ad9013ad542f3f4306160e16e67a787). The prompt during installation still showed a temporary msi name. It is something I remember looking into with Ray a while ago, and from my memories it was more something intrinsic to the way how cpack generates the installer. Might be wrong though. Will point him to this task.
Ray molenkamp commented 2024-09-05 13:37:54 +02:00
Copy Link

i'd probably try if

msiexec /l * blender.log /i blender-4.2.1-windows-x64-test.msi sheds any light on what's going on there

i'd probably try if `msiexec /l * blender.log /i blender-4.2.1-windows-x64-test.msi` sheds any light on what's going on there
Ray molenkamp commented 2024-09-05 15:13:36 +02:00
Copy Link

Looks there's something wrong with your test file, it indeed doesn't seem to work, when i resign it my self however using

signtool sign /FD SHA256 /f lazydodo.pfx /p lolno /d "It's a me, blender 4.2.1" /du "https://www.lazydodo.com" blender-4.2.1-windows-x64-test.msi

it works just peachy

image

do note this is a cosmetic fix only, all the msi rename shenanigans behind the scenes will still take place, it's just what windows does, so it'll still have some random filename inside C:\Windows\Installer\ but for the end user it'll just slap a more pleasant looking label on the ui side of things.

Looks there's something wrong with your test file, it indeed doesn't seem to work, when i resign it my self however using `signtool sign /FD SHA256 /f lazydodo.pfx /p lolno /d "It's a me, blender 4.2.1" /du "https://www.lazydodo.com" blender-4.2.1-windows-x64-test.msi` it works just peachy ![image](/attachments/56c33cc6-efe6-48a5-b390-7d233b7a1e39) do note this is a cosmetic fix only, all the msi rename shenanigans behind the scenes will still take place, it's just what windows does, so it'll still have some random filename inside `C:\Windows\Installer\` but for the end user it'll just slap a more pleasant looking label on the ui side of things.
image.png
16 KiB
xan2622 commented 2024-09-05 16:22:35 +02:00
Author
Copy Link

do note this is a cosmetic fix only, all the msi rename shenanigans behind the scenes will still take place, it's just what windows does, so it'll still have some random filename inside C:\Windows\Installer\ but for the end user it'll just slap a more pleasant looking label on the ui side of things.

IMO, it doesn't matter much if the filename inside 'C:\Windows\Installer' is random. The end user generally doesn't care about the behind-the-scenes details of the installation process.
What truly matters is that the UAC displays a more reassuring filename than 'd5b9d.msi'.
Thank you for fixing this "annoyance" (which could have lead some users to scan their installer.msi file or their whole OS for viruses or malwares, just in case..).

> do note this is a cosmetic fix only, all the msi rename shenanigans behind the scenes will still take place, it's just what windows does, so it'll still have some random filename inside `C:\Windows\Installer\` but for the end user it'll just slap a more pleasant looking label on the ui side of things. IMO, it doesn't matter much if the filename inside 'C:\Windows\Installer\' is random. The end user generally doesn't care about the behind-the-scenes details of the installation process. What truly matters is that the UAC displays a more reassuring filename than 'd5b9d.msi'. Thank you for fixing this "annoyance" (which could have lead some users to scan their installer.msi file or their whole OS for viruses or malwares, just in case..).
Sergey Sharybin commented 2024-09-05 17:08:17 +02:00
Owner
Copy Link

Ah, think I see what went wrong, and now it seems to work locally. Do you mind re-downloading the test build (SHA256 should be df131d2269c4412845d975445240cf112b71c6fa6b4b6d3aa8850f0de02b5e3c) and verify it on your end?

Ah, think I see what went wrong, and now it seems to work locally. Do you mind re-downloading the test build (SHA256 should be df131d2269c4412845d975445240cf112b71c6fa6b4b6d3aa8850f0de02b5e3c) and verify it on your end?
Ray molenkamp commented 2024-09-05 17:19:27 +02:00
Copy Link

that seems to have done the trick,

image

including the version be nice, but i'll admit, nitpicking at this point

that seems to have done the trick, ![image](/attachments/5fc500dc-43fc-49cb-812f-ffef4f13a869) including the version be nice, but i'll admit, nitpicking at this point
image.png
16 KiB
Sergey Sharybin commented 2024-09-06 11:33:52 +02:00
Owner
Copy Link

@LazyDodo We should be able to include the version. I was doing some quick manual tests on the codesign scripts. Still would need to update the packaging pipeline of the buildbot. We should be able to have access to the version from there.

@LazyDodo We should be able to include the version. I was doing some quick manual tests on the codesign scripts. Still would need to update the packaging pipeline of the buildbot. We should be able to have access to the version from there.
xan2622 commented 2024-09-06 11:37:21 +02:00
Author
Copy Link

Would it be difficult to replace the generic "application" icon with the official Blender logo ?

Would it be difficult to replace the generic "application" icon with the official Blender logo ?
Sergey Sharybin commented 2024-09-06 11:39:49 +02:00
Owner
Copy Link

@xan2622 No clue at this time :) Would be weird if that's something that is to be done via codesign. So even if it's possible, it should be handled separately from this task.

@xan2622 No clue at this time :) Would be weird if that's something that is to be done via codesign. So even if it's possible, it should be handled separately from this task.
Ray molenkamp commented 2024-09-06 15:32:37 +02:00
Copy Link

Would it be difficult to replace the generic "application" icon with the official Blender logo ?

not possible with just .msi files, if we wrapped it inside some bootstrapper exe perhaps, but that's not a route i'm interested in taking

> Would it be difficult to replace the generic "application" icon with the official Blender logo ? not possible with just .msi files, if we wrapped it inside some bootstrapper exe perhaps, but that's not a route i'm interested in taking
Sergey Sharybin commented 2024-10-04 12:43:44 +02:00
Owner
Copy Link

I've deployed the changes to the codesign and buildbot. It should properly set description to Blender <version>.
Thanks for the report and tests!

I've deployed the changes to the codesign and buildbot. It should properly set description to `Blender <version>`. Thanks for the report and tests!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/codesign#1
No description provided.
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?