mirror of
https://github.com/Set-OutlookSignatures/Set-OutlookSignatures.git
synced 2026-04-26 10:45:52 +03:00
[GH-ISSUE #120] Set-OutlookSignatures.ps1 and SimulateAndDeploy.ps1 HashMismatch #52
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Set-OutlookSignatures-Set-OutlookSignatures#52
Loading…
Add table
Add a link
Reference in a new issue
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?
Originally created by @koliwbr on GitHub (Jul 25, 2024).
Original GitHub issue: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/120
Originally assigned to: @koliwbr on GitHub.
Issue happens in the latest release
Previously solved issues and documentation
Code of Conduct
What happened?
I downloaded the latest release (the zip hash matches), when trying to run powershell it reports an error related to the signature. I checked the file hash and it matches the one in
hashes.txtI checked the file signature with the command from the release description and filesSet-OutlookSignatures.ps1andSimulateAndDeploy.ps1have a status ofHashMismatch.I checked two older releases and the same files had the same problems.
How can I fix this?
From
hashes.txt:@GruberMarkus commented on GitHub (Jul 25, 2024):
Hi @koliwbr,
are you sure that you are using the correct files?
The following code downloads a copy of v4.13.0 to a temporary file, decompresses it to a temporary folder and checks all ps*1 and dll files for digital signatures. All test systems the code has been run on reported valid signatures.
Please test the code on your own systems and report the results.
@koliwbr commented on GitHub (Jul 25, 2024):
Set-OutlookSignatures.ps1andSimulateAndDeploy.ps1still have a status ofHashMismatch@GruberMarkus commented on GitHub (Jul 25, 2024):
My tests
I tested the code from https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/120#issuecomment-2250148266 on three completely independent Windows systems (Windows 11 24H2), a Linux system (Ubuntu 24.04 LTS) and on macOS (14.5).
PowerShell 7.4.3 was used on all platforms, on Windows also PowerShell 5.1.
The signatures were valid every single time on Windows.
PowerShell on Linux and macOS does not support Get-AuthenticodeSignature yet, but Get-FileHash reported the correct hashes ( the signature is part of the file, so it is also part of the hash - see next section for thoughts on this).
In other words: I am not able to reproduce the problem.
My thoughts
The SHA 256 file hash of Set-OutlookSignatures is 39D79359E36743722172E250F07DE4AA995E0DCA4ED80D441A08F7988BF1D095 in all possible sources: The GitHub download, hashes.txt, our build system, your test system.
The digital signature is part of Set-OutlookSignatures.ps1, it's the commented block at the end of the file. So the file hash includes the certificate.
Additionally, the file hash of the downloaded ZIP file containing Set-OutlookSignatures matches the hash in the release notes, which in turn equals the file hash in our build system.
Considering all these fact, I guess it is safe to assume that the code has not been modified. At least I have no idea where and how this could happen.
The file hash on your system is not different from the release notes and my systems. I have no idea how you can get a "HashMismatch".
Your environment and your thoughts
What do your test systems look like?
What does (file) Explorer say about the validity of the signature?
@koliwbr commented on GitHub (Jul 26, 2024):
I checked the signature in Explorer and it shows that it is incorrect. This computer is in the domain, so on another outside the domain I checked the file is correct and it is still not valid.
From your description I understood that you checked the signature on one windows machine and whether the file is identical on linux/mac os. Is it the same machine that is used to sign these files? Perhaps you have extra certificates installed or something similar which marks the file as correctly signed.
When I ran Windows Sandbox and moved the file there it was marked as incorrect.
Can you confirm that in Windows Sandbox or a clean system installation the file is still marked as valid? Maybe this will help you reproduce the problem.
My OS is Windows 10 Enterprise 22H2
@GruberMarkus commented on GitHub (Jul 26, 2024):
Tests were performed on five systems in total: Three independent Windows 11 systems, one Linux system, one macOS system.
The Windows systems are not domain or Entra ID joined. One system runs in AWS, one in Azure, one on a local Hyper-V system. All three have been automatically installed from scratch using the most recent Microsoft W11 image a few days ago. Nothing more than the configuration options required for setup has been modified.
I even installed a fresh Windows 10 22H2 VM just now. Same result: The certificate is valid.
Test and dev environment are, of course, separated. No system has additional certificates installed locally, as the signing certificates are stored in a HSM module, and only the build system has access to them.
Following your proposal, I installed Windows Sandbox on one of the three test systems mentioned. The signatures are valid.
The great people from our partner (ExplicIT Consulting)[https://explicitconsulting.at] were so nice to run the validation script in their production and test environments. Thanks, Bettina!
Windows 10, Windows 11, and in Windows Sandbox on Windows 10 all tests were positive.
ExplicIT also confirmed that they are not aware about any issue with the certificate, and they have multiple clients where AppLocker actively checks the signature before Set-OutlookSignatures is allowed to run.
It seems there must be something on your end that leads to the problem.
@koliwbr commented on GitHub (Jul 26, 2024):
Thank you for checking, I will continue to look for the problem on my side. I don't see the point in uploading the file - the hash confirms that we have the same file. I am closing this issue, and thank you again for your time.