Loosen dependency on x25519-dalek

[gmulhearn-anonyome]

Description

Currently x25519-dalek within indy-utils (master, and since ~v0.5.1) is locked to =1.2:

x25519-dalek = { version = "=1.2", default-features = false, features = [
    "u64_backend",
], optional = true }

This is a problematic dependency lock, as x25519-dalek@1.2.0 has a hard dep lock on zeroize = "=1.3": https://crates.io/crates/x25519-dalek/1.2.0/dependencies.

Meaning that any other dependencies which depend on a higher version of zeroize (e.g. anoncreds depending on zeroize 1.5.7+) will fail to compile within a project alongside indy-utils... Ideally projects should depend on zeroize = "1" wherever possible, but in aries that does not seem to be the case, so having indy-utils force a lock on zeroize = 1.3 is problematic.

Some examples:

Note that these examples yield the same results when using 0.6.0 or the main branch of indy-utils (i.e. indy-utils = { git = "https://github.com/hyperledger/indy-shared-rs.git", branch = "main" })

Latest anoncreds + indy-utils

[dependencies]
anoncreds = { git = "https://github.com/hyperledger/anoncreds-rs.git", tag = "v0.1.0" }
indy-utils = "0.6.0"

> cargo check
    Updating git repository `https://github.com/hyperledger/anoncreds-rs.git`
    Updating crates.io index
error: failed to select a version for `zeroize`.
    ... required by package `anoncreds v0.1.0 (https://github.com/hyperledger/anoncreds-rs.git?tag=v0.1.0#9c915bb7)`
    ... which satisfies git dependency `anoncreds` of package `aries-dep-conflicts-resolution v0.1.0 (/Users/gmulhearne/Documents/dev/rust/aries-dep-conflicts-resolution)`
versions that meet the requirements `^1.5.7` are: 1.6.0, 1.5.7

all possible versions conflict with previously selected packages.

  previously selected package `zeroize v1.3.0`
    ... which satisfies dependency `zeroize = "^1"` (locked to 1.3.0) of package `curve25519-dalek v3.2.0`
    ... which satisfies dependency `curve25519-dalek = "^3"` (locked to 3.2.0) of package `ed25519-dalek v1.0.1`
    ... which satisfies dependency `ed25519-dalek = "^1.0"` (locked to 1.0.1) of package `indy-utils v0.6.0`
    ... which satisfies dependency `indy-utils = "^0.6.0"` (locked to 0.6.0) of package `aries-dep-conflicts-resolution v0.1.0 (/Users/gmulhearne/Documents/dev/rust/aries-dep-conflicts-resolution)`

failed to select a version for `zeroize` which could resolve this conflict

Latest Askar + indy-utils

[dependencies]
aries-askar = "0.2.9"
indy-utils = "0.6.0"

cargo check
    Updating crates.io index
error: failed to select a version for `x25519-dalek`.
    ... required by package `askar-crypto v0.2.5`
    ... which satisfies dependency `askar-crypto = "^0.2.5"` of package `aries-askar v0.2.9`
    ... which satisfies dependency `aries-askar = "^0.2.9"` of package `aries-dep-conflicts-resolution v0.1.0 (/Users/gmulhearne/Documents/dev/rust/aries-dep-conflicts-resolution)`
versions that meet the requirements `=1.1` are: 1.1.1, 1.1.0

all possible versions conflict with previously selected packages.

  previously selected package `x25519-dalek v1.2.0`
    ... which satisfies dependency `x25519-dalek = "=1.2"` of package `indy-utils v0.6.0`
    ... which satisfies dependency `indy-utils = "^0.6.0"` of package `aries-dep-conflicts-resolution v0.1.0 (/Users/gmulhearne/Documents/dev/rust/aries-dep-conflicts-resolution)`

failed to select a version for `x25519-dalek` which could resolve this conflict

Note that aries-askar@0.2.9 depends on x25119-dalek =1.1, which is also problematic and might need to be re-assessed in the askar crate. However it is somewhat less restrictive that =1.2, as at least =1.1 does put the restriction on zeroize = =1.3

History of the dep:

It's always interesting when a crate locks a dependency version, as it can be problematic. Looking at the history on indy-utils, it was previously locked at =1.1, and then updated to =1.2 as part of some routine updates: f22fc86

So it makes me wonder if it was intentional to keep the dependency locked with = and makes me wonder if there was a reason to lock it to =1.1 in the first place?

Solution

Short term

I believe a quick short-term solution to get the holy trinity (indy-shared-rs, aries-askar & anoncreds) compiling together without dep conflicts, would be to loosen the x25519-dalek dependency in indy-utils, from =1.2 to 1.1.

This will allow the following:

1. when using indy-utils in a rust project alongside the latest anoncreds and/or askar dependencies, cargo will be able to resolve x25519-dalek to a version (1.1.1) which does not cause the common zeroize versioning pain (or any other pain)
2. I also believe that it will not cause any changes with the indy-credx binaries (i.e. for the python wrapper) that are produced by this project's pipelines. As when we do a cargo buildon this project in isolation, cargo will automatically resolve x25519-dalek to1.2`.

I've made a PR with this solution: #37

Verification

It can be verified to solve the issue with the following project setup:

[dependencies]
aries-askar = "0.2.9"
indy-utils = { git = "https://github.com/anonyome/indy-shared-rs.git", branch = "gm/dep-resolve-attempt" }
anoncreds = { git = "https://github.com/hyperledger/anoncreds-rs.git", tag = "v0.1.0" }

 cargo check
    Updating git repository `https://github.com/hyperledger/anoncreds-rs.git`
    Updating crates.io index
    Finished dev [unoptimized + debuginfo] target(s) in 7.94s

Longer term

The longer term solution would be to have aries crates that consume x25519-dalek update to version "2" of the crate (namely askar and indy-utils). Ideally this would be done in a coordinated manner across the crates (including in the indy-vdr crate which deps on indy-utils).

x25119-dalek@2 would be nice, as it depends on zeroize = "1" (lots of wiggle room). but i don't know enough to know how big of an effort this is