Windows_exporter: One release 0.6.0 - not same SHA256

[dragoangel]

Hi, date of release 0.6.0 and link to file was not changed, but file, and SHA256 was modified. This is not OK, right?

[carlpett]

Hi,
I'm not sure I understand what you mean, but that shouldn't happen, correct. Could you explain a bit more what you did?
I just tested downloading all the binaries and they match the sha256sums file.

[pete-leese]

I see this too when installing via choco.

Downloading prometheus-wmi-exporter.install 64 bit
from 'https://github.com/martinlindhe/wmi_exporter/releases/download/v0.6.0/wmi_exporter-0.6.0-amd64.msi'
Progress: 100% - Completed download of C:\Users\xxxxx\AppData\Local\Temp\chocolatey\prometheus-wmi-exporter.install\0.6.0\wmi_exporter-0.6.0-amd64.msi (5.88 MB).
Download of wmi_exporter-0.6.0-amd64.msi (5.88 MB) completed.
Error - hashes do not match. Actual value was '56F8DECE5A71CF387A2E08FCF15541E8C6061F1D287A19A339CC6637012461D2'.
ERROR: Checksum for 'C:\Users\xxxxxx\AppData\Local\Temp\chocolatey\prometheus-wmi-exporter.install\0.6.0\wmi_exporter-0.6.0-amd64.msi' did not meet '404E8CAED8500DAC437386C6F6C19904706360658E79EED1CBBAE2466660DB88' for checksum type 'sha256'. Consider passing the actual checksums through with --checksum --checksum64 once you validate the checksums are appropriate. A less secure option is to pass --ignore-checksums if necessary.
The install of prometheus-wmi-exporter.install was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\prometheus-wmi-exporter.install\tools\chocolateyinstall.ps1'.
See log for details.

[carlpett]

Ok, I see what you mean now - the files have been updated since the original release (checked via Github API and also comparing the stored artifacts in AppVeyor CI). Will investigate with haste.

[carlpett]

Found it. Luckily non-malicious, human error (and somewhat confusing that this is possible, but that is a separate issue).

Here's the timeline:

• 2019-02-01: v0.6.0 is released, and artifacts built
• 2019-03-05: Package is marked as trusted on Chocolatey. I assume this includes uploading checksums?
• 2019-03-13 17:39: I triggered a rebuild the previous build on master yesterday to debug some issues we were having on building a PR. The previous build on master happened to be the commit tagged 0.6.0, and therefore AppVeyor uploaded new artifacts.

The reason the checksums do not match after rebuilding is that we stamp the build-time into the binary.

I have sent a message to the maintainer of the chocolatey package asking how to best proceed.

I'm terribly sorry for causing this, and will have a look at what we can change in the automation to ensure this cannot happen again!

[carlpett]

Actually, perhaps it is sufficient if I re-upload the old binaries from AppVeyor? Could someone with more Chocolatey insights advice if this would make things better or worse?

[dragoangel]

Point in that for example I use WMI exporter with hardcoded version and I think that one version musn't change it SHA over time so same as Chocolatey I hardcoded SHA from your file to my Chef. After yersturdey all deploy goes down because SHA was changed and Chef fail deploy with fatal error.

[dragoangel]

About Chocolatey I don't know what to do - maybe there a way to update SHA for existing release. I was uploaded "new" 0.6.0 msi to virustotal and not find any isses so I updated my hardcoded SHA to "new" ones, but before of it I have many failed deploys. :(. So if you plan return previous build pls PM me =)

[pete-leese]

you should just be able to upload old binaries.

The choco install is just a powershell wrapper that is looking for the binaries;

$url = 'https://github.com/martinlindhe/wmi_exporter/releases/download/v0.6.0/wmi_exporter-0.6.0-386.msi'
$url64 = 'https://github.com/martinlindhe/wmi_exporter/releases/download/v0.6.0/wmi_exporter-0.6.0-amd64.msi'

later in the script it checks that the checksum in the tools\chocolateyinstall.ps1 script matches.

Alternatively the maintainer can update the checksum in the tools\chocolateyinstall.ps1 script - however but as you have just released 0.7.0 I would expect the maintainer to update the package accordingly.

Andrew is usually pretty quick doing this once he is made aware of a new release.

[mst-ableton]

@carlpett thanks for the quick response on this! Much appreciated.

[andrewmostello]

Hi everyone - I'm the maintainer of the Chocolatey package, and I'll take care of it shortly. I just updated the package for the 0.7.0 release, so that should be available soon and this will be moot, but I'll see about pushing and updated choco package of the 0.6.0 release with the updated checksums.

As noted above, the choco package is locked to the checksums of the binaries, so if they change the install will fail. If that happens, like in this case, I'll update the package with the updated checksums and that will take care of it.

[dragoangel]

@andrewmostello yes, but it musn't happen in future, because released package without changing of version must be same binary file all time.

[carlpett]

@dragoangel Fully agree, it most certainly must not happen again. I will add some safeguards to our build scripts. Also, many thanks for reporting!

@andrewmostello Thanks for responding! If you haven't already updated the package, from my understanding it might be better to reupload the old binaries in order to not break users who like @dragoangel who put the checksums in other tooling? What do you think?
(Unless you already updated, in that case it would probably just stir things up even more for people who got the rebuild binaries...)

[andrewmostello]

@carlpett yesterday I pushed up a package fix version to Chocolatey (version 0.6.0.20190314), so I wouldn't re-upload the old binaries. If anyone wants to install the latest 0.6.0 build with the updated checksums, they can specify that version and it will install properly. 0.7.0 has been approved by Chocolatey now as well, so I don't think many people will run into the issue.

That version number is to Chocolatey's specifications, so it should be clear that it's version 0.6.0 with a change to the Chocolatey scripts.
https://chocolatey.org/docs/create-packages#package-fix-version-notation

[carlpett]

Sounds good :+1: Thanks for the help!

I will close this issue once the build script enhancements are done.

[andrewmostello]

No problem! Updating the package is quick, so it's not a big deal. Happy to help.

[dragoangel]

@carlpett - anyone who use some Software Automative Configuration of Compute resources can relly on it. For exemple if somebody use autoscaling groups in AWS with Chef:
This soft use your "cookbook" to run what you need. Like download and install wmi_exporter.msi. It will check SHA256 of downloaded file with SHA256 from Chef cookbook. If SHA256 not match then Chef run will fail, and EC2 in autoscaling group will fail too because nobody not need broken deployed EC2. So this will broke AWS upscaling.