WinRAR 5.40.0.20161221 checksum mismatch

[Redsandro]

Checksum for 'C:\Users\IEUser\AppData\Local\Temp\chocolatey\winrar\winrarInstall.exe' did not meet 'ea70bdaf4336db36f564562dc58daf41816f86eeeb904c22b375431932c3faf8' for checksum type 'md5'.
At C:\ProgramData\chocolatey\helpers\functions\Get-CheckSumValid.ps1:51 char:10

The install of winrar was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\winrar\tools\chocolateyInstall.ps1'.

http://disq.us/p/1g0enct

[dtgm]

Can confirm

http://www.win-rar.com/predownload.html?&L=0 32-bit SHA256 is 900c5a3195b9490e7b1db35366ed79261eb6193b61692c96ebeeb3ee18fbe604

http://www.win-rar.com/predownload.html?&L=0&Version=64bit 64-bit SHA256 is db1eb17243de9669824344644d0c4b4920425d8083c9707c9a50d60e3ca74a18

Package expects

  $url = $url+$url_version+'.exe'
  $checksum = 'ea70bdaf4336db36f564562dc58daf41816f86eeeb904c22b375431932c3faf8'
  $checksumType = 'sha256

or

  $url64 = $url64+$url_version+'.exe'
  $checksum64 = 'd73cc6a97c3edde637c7d952ee2e0efc5b09937e5300cb0ecaffda70f4efdef0'
  $checksumType64 = 'sha256'

However, I'm confused, both files were signed ‎2016-08-15 but I added the checksum for the English version on 2016-12-21.....so I went back and looked at the EXE I used to create the package on 2016-12-21 and the digital signature timestamp is oddly 2016-08-14. So I'm left wondering can the timestamp be manually set when signing?

[dtgm]

It seems really weird that the EXE would be updated on win-rar.com 6 months after being signed. And also being signed only a day after the previous version was released...

[Redsandro]

Thank you for looking into this @dtgm. It seems weird indeed.

Perhaps the binary was updated but the site didn't reflect these updates. Perhaps the version was the same, just a rebuild of the installer. Fixed a bug; or updated a tracker in the installer. And RarLabs didn't want people to worry about it.

I'm left wondering can the timestamp be manually set when signing?

I think so. I remember being able to change a lot of details about .exe files when I was still a kid messing around. Many summers ago, but still.

We can speculate, but the package being previously approved proves that things can change upstream.

I don't know how often this happens (to packages in general) but we could use an early warning system (Preferably an auto-repackage system): https://github.com/chocolatey/choco/issues/1160

[dtgm]

Perhaps the binary was updated but the site didn't reflect these updates. Perhaps the version was the same, just a rebuild of the installer. Fixed a bug; or updated a tracker in the installer. And RarLabs didn't want people to worry about it.

Yup, I'm very familiar with these "silent" updates. I've been using checksums on all of my 900+ packages for 2+ years now, all while also saving every installer file used to create each package's checksum because I anticipated this very situation and wanted to be able to go back and properly troubleshoot what was going on. Because from my perspective, I don't know if the change is harmless or if the system was compromised and the file maliciously swapped out. I guess a re-packager could automatically run the new install file against virustotal.com engine and trust that result.

Another example of a program that doesn't track builds is freefilesync, see issue #234 and the disqus comment (below)

The installer is constantly changed (maybe because of the advertisements). Please remove the checksum check. Otherwise this annoying problem stays.

I won't be removing the checksum to alleviate the error. This is exactly the intent of the checksum to provide this modicum of security. It indicates to users that the install file is not the one that was used to create the package. If a user doesn't care about that or wishes to trust the package anyway, then they can easily bypass this security check by passing the choco option:

--ignorechecksum, --ignore-checksum, --ignorechecksums, --ignore-checksums

during install/upgrade. Also ignoring the checksum doesn't resolve the larger issue that 'choco upgrade freefilesync' won't work if the installer is silently being upgraded. One would need to routinely reinstall the program blindly.

Unfortunately, my pkg build process isn't automatic for these sorts of scenarios and the pkg must be built manually for now. While I could implement a workaround hack, I would prefer this be addressed and fixed upstream by the developers of freefilesync.

[Redsandro]

Ah yes, I can imagine. Automatic rebuilds would need to depend on a virus check indeed. You manage an impressive amount of packages. If you're considering options, it's interesting to know that the VirusTotal API allows up to 4 requests per minute.

FreeFileSync in particular is a bit strange. I use it often (Linux version) but it's hard to find versions that work because even though it's Open Source, the build is not very well documented and hard to do.

I think the dev (speculation) wants to make it hard so they have the exclusive know-how to build the (Windows) binary and in order to get a bit of revenue, the installer is updated more often than the software itself.

[tunisiano187]

@gep13 , you can close this one, it's maintained by @mkevenaar

[gep13]

@tunisiano187 :+1: