Ic-state-machine-tests has a lot of outdated dependencies

Can we update the ic-state-machine-tests library dependencies to ones that aren’t outdated and don’t have security vulnerabilities? Here a list:

image

image

image

image

They are flagged by cargo for every package/canister that gets built.

They:

  • fill up the entire terminal with long lines of dependency tree text that makes it infeasible to check out earlier terminal output
  • are flagged by dependabot as security vulnerabilities in our Github repo
  • overall a security vulnerability even though they are limited to testing environments only.

Thoughts?
@roman-kashitsyn

P.S. I’m on a new-ish version of ic-state-machine-tests. Specifically from this commit.

3 Likes

Hi @saikatdas0790

I’m in the process of open sourcing a new library that can run the state-machine-test infrastructure as a pre-built binary.

Switching to that library will decouple your project from the IC repo completely, which will not only resolve the warnings but also speed up compile time a lot.

I’ll report back once the library is available via crates.io.

4 Likes

Hi @saikatdas0790

The library is now available on crates.io. For inspiration on how to use it, you can take a look at the integration tests in the Internet Identity repository.

Be aware, that it takes a while for a new IC commit to have the pre-built binary available. So if it does not work for the latest commit on master, maybe try a few older commits.

Lastly, the client library is incomplete. I.e. it has not all the features of the test-state-machine yet, but the client library repository is open to contributions.

I hope this resolves your issues. Let me know if you run into problems.

5 Likes

Thank you so much for this. I’ll give it a try.

Here’s a friendly suggestion. It would be really helpful if we could list the missing features of the library compared to ic-state-machine-tests in the readme and mark them as done as more get implemented.

Otherwise, looks good.

I’ll come back with issues/feedback once I’ve tried it out on a large repo that uses ic-state-machine-tests right now. Give me a couple of days

Any plans to make the ic-state-machines-test work with http requests/ ecdsa signing? This would be very useful for many teams working in Rust.

Hi @Maxfinity

Calling the http_request query on a canister is already supported. There are no plans to include an actual HTTP gateway to that infrastructure. If you require that, it would need to be added externally.

I’m not sure about ECDSA support. I’ll ask internally.

Hi @frederikrothenberger,

I’ve been working on migrating some of our tests over to this new binary and am stuck on this:

When provisioning a new canister, how does one specify the controllers of that canister? Specifically, I’m looking at this function.

Earlier, I was using these 2 functions to accomplish the same. They take an optional setting parameter which let us define the controllers.

Thoughts?

Hi @saikatdas0790

You caught me being a bit lazy on the wrapper, sorry about that. There are two options here:

  1. Expand the wrapper (i.e. create a PR) to provide an easy to use function to pass in the CanisterSettings similar to this function.
  2. Manually issue a call to the ManagementCanister: I.e. you can send an UpdateCall to the ManagementCanister according to the interface spec here. I.e. do this:
let CanisterIdRecord { canister_id } = call_candid(
            self,
            Principal::management_canister(),
            "create_canister",
            (CreateCanisterArgument { settings: None },),
        )
        .map(|(x,)| x)
        .unwrap();

in your test and modify the settings to your liking.

If you have the time to spare, I would appreciate the PR to make the wrapper more convenient. :wink:

1 Like

Quick update on this matter:

I’m not sure about ECDSA support. I’ll ask internally.

Both HTTP outcalls and ECDSA signing would be possible to support, however there is no urgent need internally, so the priority is rather low unfortunately.

Okay. I’ll send you a PR :slight_smile:

1 Like

Hi @frederikrothenberger,

I sent you a pull request here. Let me know if you have any feedback.

Otherwise feel free to merge and publish a new version. Thank you :slight_smile:

Hi @saikatdas0790

Thanks for your contribution!

Version 1.1.0 of the ic-test-state-machine-client crate has been published.

1 Like

Hi @frederikrothenberger

I’m looking at the integration tests in the II canister here:

and they reference a binary that I’m not sure where to obtain from. Thoughts?

Hi @frederikrothenberger

Any thoughts on the above?

Hi @saikatdas0790

Are you talking about the STATE_MACHINE_BINARY? This is the file downloaded from https://download.dfinity.systems/ic/$commit/binaries/$platform/ic-test-state-machine.gz as later explained in the error message of this function
(which is the same as mentioned in the Readme here).

1 Like

Hi @frederikrothenberger

I managed to get the binary from the URL as instructed. However, the binary runs into the following error when I try to execute it.

I’m on Linux, btw

Thoughts?

Also, on a side note, is it not possible to ship the binary along with the library to crates.io to eliminate this confusing manual intermediate step?

Hi @frederikrothenberger

Any updates on this? Is it possible to bundle the binary along with the Rust libary so that it just works? Let me know how to proceed.

Also, please provide inputs here if there’s something that can help.

Thank you

Hi @saikatdas0790

I’m really not sure, why this would not work for you. We have our CI running on Ubuntu, and it executes those exact commands. See here: internet-identity/canister-tests.yml at main · dfinity/internet-identity · GitHub

Could it be that you are running some other platform than x86_64?

As for bundling the binary into the lib: The binary is built from the IC repository using bazel, see here: ic/BUILD.bazel at master · dfinity/ic · GitHub

Given that the whole point of the binary is to decouple the client lib from the IC repository (and the bazel build process), I’d rather not reintroduce the dependency. Also, cargo is not really suited to distribute prebuilt binaries.

If you could try building the binary yourself directly from the IC repo, maybe you can get a version that runs on your machine?

@PaulLiu Are there any specific steps I need to take or configure to make the binary work on NixOS?

Any inputs you have would be helpful

The binaries downloaded from https://download.dfinity.systems are dynamically linked, and they have hardcoded library paths that may not exist on NixOS. Usually this can be fixed either by using patchelf on the downloaded binary itself, or by setting LD_LIBRARY_PATH. See Packaging/Binaries - NixOS Wiki for more explanation.