search

hyperledger / anoncreds-rs

anoncreds-rs
https://wiki.hyperledger.org/display/anoncreds
Apache License 2.0
71 stars 52 forks source link

General request to loosen dependency versions wherever possible #240

Open gmulhearn-anonyome opened 12 months ago

gmulhearn-anonyome commented 12 months ago

Hi, just posting a general query on this crate and others in the aries ecosystem...

I'd like to open discussion about 'loosening' some of the dependency versions in Cargo.tomls of aries crates. As a rust consumer of the crates (as opposed to a consumer via the python/js wrappers on top of pre-compiled binaries), it can be very difficult to pull in multiple hyperledger aries crates into due to the differing tight dependency versions between them...

particularly, the aries-askar, indy-vdr (transitively the indy-shared-rs crates too) & anoncreds-rs stack (i.e. the modern? aries stack) is difficult to pull together in rust due to dependency conflicts amongst tight dependency versions. IMO it would be a great goal to aim to have the latest versions of these crates compatible with one another.

An effort towards this goal would also greatly help the aries-vcx project as they push towards this modern stack.

FWIW, the most common conflicting dependency amongst the stack tends to come from zeroize:

for instance; indy-vdr depends on indy-utils, which depends on zeroize = "1.3" (which is mostly reasonable since that means >= 1.3 & < 2.0), but it also hard-locks a dependency on x25519-dalek = "=1.2", and the x25519-dalek 1.2 hard-locks a dependency on zeroize "=1.3" :(. So this makes indy-vdr incompatible with anoncreds-rs (assuming zeroize feature is enabled) and also incompatible with aries-askar. P.S. upgrading to x25119-dalek @ 2.0 fixes this, as they've since revised their zeroize dependency to = "1".

But there are many other instances of other dependencies that may cause conflict due to dep strictness.

So yeah, please let me know what you think. Maybe it's not as bad as i think and I'm doing something wrong with my cargo dependency management..

P.S. posting here as anoncreds-rs seems to be the most active of the crates I've mentioned, not necessarily because it's the main perpetrator of dep strictness 😅

berendsliedrecht commented 12 months ago

I am not opposed to fixing this, preferably by updating deps like x25519-dalek instead of lowering zeroize in anoncreds-rs. Is this something the vcx team can pick up as it would be a lot easier for you to discover the issues and create pull requests for them. I'd be happy to accept them.

gmulhearn-anonyome commented 12 months ago

Thanks for the reply. Yea agreed that x25519-dalek updating (i.e. to "2") would be the ideal solution.

I've started a thread/PR in indy-utils (which is where i think the root of the immediate issue is), seeking that they loosen their x25519-dalek dependency. As this seems to immediately allow anoncreds, askar and indy-vdr to play nicely together.

However long-term would be for everyone to coordinate a x25519-dalek@2.0 upgrade

https://github.com/hyperledger/indy-shared-rs/issues/38

swcurran commented 12 months ago

@andrewwhitehead — what do you think of this synchronization across the shared components?

andrewwhitehead commented 12 months ago

I think ed/curve/x25519-dalek had to be locked due to an incompatibility with the RustCrypto crates, but they have recently gotten some new maintainers and releases and we should be able to update now, hopefully. In general I agree with making the dependencies compatible but it can be tricky sometimes.

andrewwhitehead commented 11 months ago

I have a local branch updating the indy-utils ed25519 support for the 2.0 versions, it's not a huge change. It looks like this would also address a new CVE against the older versions.

I plan to release a new indy-credx patch version with the latest updates (staying on 1.1) before updating to 2.0 in a new minor release. aries-askar is also due for a new release, but I'm not certain if it's desirable to update to the 2.0 versions before that, or wait for the next one.

Given that indy-utils and indy-data-types are both used in indy-credx and indy-vdr currently (and nowhere else), I think it makes sense to merge indy-utils into indy-data-types for the next breaking release. Instead of re-implementing the ed25519 support it would be possible to depend on askar-crypto for this, but that might further complicate the dependency picture (unless it helps to guarantee compatibility?).