Different hashing algorithms in updater and building script

[natlg]

• Parity Ethereum version: 2.2.0-nightly
• Operating system: Linux
• Installation: built from source
• Fully synchronized: no
• Network: POA Sokol
• Restarted: yes

We have contracts and auto updater server configured for the POA Sokol Network, it worked with the old version of CI. Now after building it pushes a sha256 hash of binary to the Operations contract.
But updater calculates a sha3 hash of binary and it doesn't match. Here is log from our test build:

parity_updater::updater  Unable to fetch update (2.2.0-nightly-0x44c4…21c4): HashMismatch { expected: 0x38db89616c5776c033465d6b7d6401bfab7412e47c1c8db4a2a95e8a8704987b, got: 0x06c38cfb06e9d6d33fba852167c7ed51e45fc4597bd66cc5517e3daeae76a566 }, retrying in 8 seconds.

Tried to use then parity tools hash in the build script , this way it works.

For reproducing you will probably need to add a push-release request to the auto updater server.

[jam10o-new]

Hey, the checksum calculated by the script you shared has never been meant to be used for the updater, as you've noticed. I'm uncertain how it's worked in the past with your setup, but we've always recommended using parity tools hash as you've correctly discovered.

A tool to help automate this process for you: https://github.com/paritytech/push-release

[natlg]

Yes, push-release is really convenient, we use it and GitLab for making releases. It's quite the same process as in your repository, so more likely auto updating will not work for any network.

This script is not used by the updater directly, here is a flow right now in the master branch:

1. Build step. Script that I mentioned builds binaries, then calculates sha256 hash of binary files and saves to the file (parity.sha256 for parity): https://github.com/paritytech/parity-ethereum/blob/93e1040d07e385d1219d00af71c46c720b0a1acf/scripts/gitlab/build-unix.sh#L34
2. Publish step. One of tasks here is to iterate parity.sha256 files for the each platform created in the build step, read a hash from it and send to the push-release server among other information: https://github.com/paritytech/parity-ethereum/blob/93e1040d07e385d1219d00af71c46c720b0a1acf/scripts/gitlab/push.sh#L35-L43
3. Push-release server receives hash and sends it to the GitHubHint contract with download url, then to the Operations contract.
4. Updater calls Operations contract to get information about new release, then uses it to get hash of the binary (saved on the previous step): https://github.com/paritytech/parity-ethereum/blob/93e1040d07e385d1219d00af71c46c720b0a1acf/updater/src/updater.rs#L223 This hash is used then to get a download url from the GitHubHint contract. https://github.com/paritytech/parity-ethereum/blob/93e1040d07e385d1219d00af71c46c720b0a1acf/hash-fetch/src/client.rs#L133
5. Updater downloads binary and validates it's hash. It calculates a sha3 hash and compares with a hash used for getting download url: https://github.com/paritytech/parity-ethereum/blob/93e1040d07e385d1219d00af71c46c720b0a1acf/hash-fetch/src/client.rs#L102-L104

So what actually happens is updater tries to compare sha256 (created on the build step) and sha3 hashes, validation fails so auto updating doesn't work.

Here is how it worked before:
calculating sha3 hash of binaries and sending it to the push-release server, but this code is changed now.

[jam10o-new]

Hey, sorry, misunderstood your report. This is a genuine issue that I've confirmed with @tomusdrw