The way it works is that the "installer" .exe program is signed by SignPath Foundation. That is the application you download from the website and requires the most serious level of certification. The .exe and .dll files inside the installer, the ones that are actually installed on your computer, are self-signed by us, as they can be trusted since they came inside the very secure installer container. When Rainmeter is auto-updated by the application itself, you don't really see the "installer", but it is indeed used to deliver the application and install it. The SHA hash of the installer is checked before it is executed by the auto-update process.I installed the latest update, but my .dll and .exe files don't have the signature you posted (Firebit OU). The 'name of signer' is 'Rainmeter Team' and the timestamp is 'not available.'
Also under 'digital signature information,' it says 'the certificate in the signature cannot be verified' and the signer information is also 'Rainmeter Team.' The certificate info indicates 'Windows does not have enough information to verify this certificate' and it says 'issued to: Rainmeter Team,' 'issued by: Rainmeter Team Root Certificate,' and 'Valid from 2/29/2024 to 2/26/2034.'
Can anyone confirm if that's all correct? It looks like all the files are from 8/8/24. I just installed this fix yesterday after the program prompted me and I checked the forum first.
EDIT: I downloaded the .exe file from the official site just to compare, but that one has a signature time stamp and verified certificate signed by 'SignPath Foundation.' I'm confused because when I clicked to update through the app, I got a prompt from Windows whether I wanted 'SignPath Foundation' Rainmeter to make changes (I figured that was the update package). Why are my 8/8/24 files signed by 'Rainmeter Team' instead? Was I not supposed to update via the application?
Thanks for any help!
So the long and the short of it is that yes, what you are seeing is correct.
The installer:The internal program files:The goal intended by "signing" the installer is to allow it to be safely downloaded. Hopefully and presumably from our website or WinGet, but really from anywhere. It allows the installer to be "trusted" by Microsoft Windows, which will require this trust in order to download and run without lots of barking and snarling. The internal application .exe and .dll files are not going to be downloaded, and don't require having to jump through these hoops. The self-signed certificate has the same effect of tying the files to our organization in a trusted way, just not using an external certificate issuing entity that is "trusted" by Microsoft.
Statistics: Posted by jsmorley — Today, 3:19 am