fix: Binstall archives were not .tar.gz

[bitdivine]

Motivation

The .tar.gz releases were not in fact .tar.gz compressed. This was hidden by some installers magically recognizing the .tar.gz file as a raw binary, but this does not make it right.

Changes

• Specify the binstall path, so that binstall knows where to download the binary from without guesswork.
• Actually package the executables as .tar.gz

Tests

Is the new Cargo.toml correct?

Binstall normally uses the Cargo manifest published to crates.io. We can use the local Cargo.toml instead with:

cargo binstall --manifest-path ./Cargo.toml ic-wasm --strategies crate-meta-data --log-level debug

This failed with a chain of errors starting with:

 WARN resolve: Error while downloading and extracting from fetcher github.com: I/O Error: invalid gzip header

• I checked the [ic-wasm-x86_64-unknown-linux-gnu.tar.gz](https://github.com/dfinity/ic-wasm/releases/download/0.5.0/ic-wasm-x86_64-unknown-linux-gnu.tar.gz) file and indeed, it was just a plain executable.
• I manually replaced that executable with the same file, tarred and zipped as in CI. Now CI worked.
• The error in CI is that the file is compressed but then the uncompressed file is uploaded.

Are the uploaded assets now really .tar.gz files?

See the release from the tag 0.5.0-ci.1. I have downloaded and tested the format of the following files:

Linux AMD64

ic-wasm-x86_64-unknown-linux-gnu.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 25221120

Decompressed, the fomat is elf as expected:
ic-wasm: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=dd5b9432fb247e9491803cc5dd2d83e2e296f0a5, for GNU/Linux 3.2.0, with debug_info, not stripped

max@sinkpad:~/Downloads (1:01:11)$ ./ic-wasm --help
Usage: ic-wasm [OPTIONS] <INPUT> <COMMAND>

Linux Arm

ic-wasm-arm-unknown-linux-gnueabihf.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 23541760

Decompressed:
ic-wasm: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 4.19.21, with debug_info, not stripped

Darwin

ic-wasm-x86_64-apple-darwin.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 30197760

Decompressed:
ic-wasm: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|PIE|HAS_TLV_DESCRIPTORS>

Does fixing the Wasm assets break existing binstall incantations?

We can test this with:

cargo binstall ic-wasm --strategies crate-meta-data

This works. You may need to use --force if you already have that version installed.