decentralized-identity / did-key.rs

Rust implementation of the did:key method

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

v0.0 branch?

vdods opened this issue · comments

commented

Due to the breaking change mess with funty (see ferrilab/funty#3), I'm finding it a bit intractable to upgrade my dependency on did-key.rs to 0.1. Would you be open to having a v0.0 branch with a 0.0.16 release? This would include the fixes to secp256k1 codec in DID resolution, correctly returning error instead of panicking, but I believe couldn't include the recent BLS key refactor.

commented

I have a working branch in a fork: https://github.com/LedgerDomain/did-key.rs/tree/v0.0

You should be able to just reference did-key = "0.1" directly, without it breaking on funty. Are you referencing any other libraries that may be breaking this change? Can you post your cargo tree?

did-key dependency tree

did-key v0.1.1 (/Users/tomislav/Git/trinsic-id/did-key.rs)
├── arrayref v0.3.6
├── base64 v0.13.0
├── bls12_381_plus v0.6.0
│   ├── digest v0.9.0
│   │   └── generic-array v0.14.5
│   │       └── typenum v1.15.0
│   │       [build-dependencies]
│   │       └── version_check v0.9.4
│   ├── ff v0.11.0
│   │   ├── bitvec v0.22.3
│   │   │   ├── funty v1.2.0
│   │   │   ├── radium v0.6.2
│   │   │   ├── tap v1.0.1
│   │   │   └── wyz v0.4.0
│   │   │       └── tap v1.0.1
│   │   ├── rand_core v0.6.3
│   │   │   └── getrandom v0.2.3
│   │   │       ├── cfg-if v1.0.0
│   │   │       └── libc v0.2.112
│   │   └── subtle v2.4.1
│   ├── group v0.11.0
│   │   ├── byteorder v1.4.3
│   │   ├── ff v0.11.0 (*)
│   │   ├── rand_core v0.6.3 (*)
│   │   └── subtle v2.4.1
│   ├── heapless v0.7.9
│   │   ├── hash32 v0.2.1
│   │   │   └── byteorder v1.4.3
│   │   ├── spin v0.9.2
│   │   │   └── lock_api v0.4.5
│   │   │       └── scopeguard v1.1.0
│   │   └── stable_deref_trait v1.2.0
│   ├── pairing v0.21.0
│   │   └── group v0.11.0 (*)
│   ├── rand_core v0.6.3 (*)
│   ├── serde v1.0.133
│   │   └── serde_derive v1.0.133 (proc-macro)
│   │       ├── proc-macro2 v1.0.36
│   │       │   └── unicode-xid v0.2.2
│   │       ├── quote v1.0.14
│   │       │   └── proc-macro2 v1.0.36 (*)
│   │       └── syn v1.0.85
│   │           ├── proc-macro2 v1.0.36 (*)
│   │           ├── quote v1.0.14 (*)
│   │           └── unicode-xid v0.2.2
│   ├── subtle v2.4.1
│   └── zeroize v1.4.3
│       └── zeroize_derive v1.2.2 (proc-macro)
│           ├── proc-macro2 v1.0.36 (*)
│           ├── quote v1.0.14 (*)
│           ├── syn v1.0.85 (*)
│           └── synstructure v0.12.6
│               ├── proc-macro2 v1.0.36 (*)
│               ├── quote v1.0.14 (*)
│               ├── syn v1.0.85 (*)
│               └── unicode-xid v0.2.2
├── bs58 v0.4.0
├── curve25519-dalek v3.2.0
│   ├── byteorder v1.4.3
│   ├── digest v0.9.0 (*)
│   ├── rand_core v0.5.1
│   │   └── getrandom v0.1.16
│   │       ├── cfg-if v1.0.0
│   │       └── libc v0.2.112
│   ├── subtle v2.4.1
│   └── zeroize v1.4.3 (*)
├── did_url v0.1.0
│   └── form_urlencoded v1.0.1
│       ├── matches v0.1.9
│       └── percent-encoding v2.1.0
├── ed25519-dalek v1.0.1
│   ├── curve25519-dalek v3.2.0 (*)
│   ├── ed25519 v1.3.0
│   │   └── signature v1.3.2
│   │       ├── digest v0.9.0 (*)
│   │       └── rand_core v0.6.3 (*)
│   ├── rand v0.7.3
│   │   ├── getrandom v0.1.16 (*)
│   │   ├── libc v0.2.112
│   │   ├── rand_chacha v0.2.2
│   │   │   ├── ppv-lite86 v0.2.16
│   │   │   └── rand_core v0.5.1 (*)
│   │   └── rand_core v0.5.1 (*)
│   ├── serde v1.0.133 (*)
│   ├── sha2 v0.9.9
│   │   ├── block-buffer v0.9.0
│   │   │   └── generic-array v0.14.5 (*)
│   │   ├── cfg-if v1.0.0
│   │   ├── cpufeatures v0.2.1
│   │   ├── digest v0.9.0 (*)
│   │   └── opaque-debug v0.3.0
│   └── zeroize v1.4.3 (*)
├── getrandom v0.2.3 (*)
├── hkdf v0.11.0
│   ├── digest v0.9.0 (*)
│   └── hmac v0.11.0
│       ├── crypto-mac v0.11.1
│       │   ├── generic-array v0.14.5 (*)
│       │   └── subtle v2.4.1
│       └── digest v0.9.0 (*)
├── libsecp256k1 v0.5.0
│   ├── arrayref v0.3.6
│   ├── base64 v0.12.3
│   ├── digest v0.9.0 (*)
│   ├── hmac-drbg v0.3.0
│   │   ├── digest v0.9.0 (*)
│   │   ├── generic-array v0.14.5 (*)
│   │   └── hmac v0.8.1
│   │       ├── crypto-mac v0.8.0
│   │       │   ├── generic-array v0.14.5 (*)
│   │       │   └── subtle v2.4.1
│   │       └── digest v0.9.0 (*)
│   ├── libsecp256k1-core v0.2.2
│   │   ├── crunchy v0.2.2
│   │   ├── digest v0.9.0 (*)
│   │   └── subtle v2.4.1
│   ├── rand v0.7.3 (*)
│   ├── serde v1.0.133 (*)
│   ├── sha2 v0.9.9 (*)
│   └── typenum v1.15.0
│   [build-dependencies]
│   ├── libsecp256k1-gen-ecmult v0.2.1
│   │   └── libsecp256k1-core v0.2.2 (*)
│   └── libsecp256k1-gen-genmult v0.2.1
│       └── libsecp256k1-core v0.2.2 (*)
├── p256 v0.9.0
│   ├── ecdsa v0.12.4
│   │   ├── der v0.4.5
│   │   │   └── const-oid v0.6.2
│   │   ├── elliptic-curve v0.10.6
│   │   │   ├── crypto-bigint v0.2.11
│   │   │   │   ├── generic-array v0.14.5 (*)
│   │   │   │   ├── rand_core v0.6.3 (*)
│   │   │   │   ├── subtle v2.4.1
│   │   │   │   └── zeroize v1.4.3 (*)
│   │   │   ├── ff v0.10.1
│   │   │   │   ├── bitvec v0.22.3 (*)
│   │   │   │   ├── rand_core v0.6.3 (*)
│   │   │   │   └── subtle v2.4.1
│   │   │   ├── generic-array v0.14.5 (*)
│   │   │   ├── group v0.10.0
│   │   │   │   ├── byteorder v1.4.3
│   │   │   │   ├── ff v0.10.1 (*)
│   │   │   │   ├── rand_core v0.6.3 (*)
│   │   │   │   └── subtle v2.4.1
│   │   │   ├── pkcs8 v0.7.6
│   │   │   │   ├── der v0.4.5 (*)
│   │   │   │   └── spki v0.4.1
│   │   │   │       └── der v0.4.5 (*)
│   │   │   ├── rand_core v0.6.3 (*)
│   │   │   ├── subtle v2.4.1
│   │   │   └── zeroize v1.4.3 (*)
│   │   ├── hmac v0.11.0 (*)
│   │   └── signature v1.3.2 (*)
│   ├── elliptic-curve v0.10.6 (*)
│   └── sha2 v0.9.9 (*)
├── serde v1.0.133 (*)
├── serde_json v1.0.74
│   ├── itoa v1.0.1
│   ├── ryu v1.0.9
│   └── serde v1.0.133 (*)
├── sha2 v0.9.9 (*)
├── signature_bls v0.30.0
│   ├── bls12_381_plus v0.5.2
│   │   ├── digest v0.9.0 (*)
│   │   ├── ff v0.10.1 (*)
│   │   ├── group v0.10.0 (*)
│   │   ├── heapless v0.7.9 (*)
│   │   ├── pairing v0.20.0
│   │   │   └── group v0.10.0 (*)
│   │   ├── rand_core v0.6.3 (*)
│   │   ├── serde v1.0.133 (*)
│   │   ├── subtle v2.4.1
│   │   └── zeroize v1.4.3 (*)
│   ├── ff v0.10.1 (*)
│   ├── group v0.10.0 (*)
│   ├── hkdf v0.11.0 (*)
│   ├── pairing v0.20.0 (*)
│   ├── rand_core v0.6.3 (*)
│   ├── serde v1.0.133 (*)
│   ├── sha2 v0.9.9 (*)
│   ├── subtle v2.4.1
│   ├── vsss-rs v1.4.0
│   │   ├── ff v0.10.1 (*)
│   │   ├── group v0.10.0 (*)
│   │   ├── rand_chacha v0.3.1
│   │   │   ├── ppv-lite86 v0.2.16
│   │   │   └── rand_core v0.6.3 (*)
│   │   ├── rand_core v0.6.3 (*)
│   │   ├── serde v1.0.133 (*)
│   │   ├── serde-big-array v0.3.2
│   │   │   ├── serde v1.0.133 (*)
│   │   │   └── serde_derive v1.0.133 (proc-macro) (*)
│   │   ├── sha2 v0.9.9 (*)
│   │   └── zeroize v1.4.3 (*)
│   └── zeroize v1.4.3 (*)
└── x25519-dalek v1.1.1
    ├── curve25519-dalek v3.2.0 (*)
    ├── rand_core v0.5.1 (*)
    └── zeroize v1.4.3 (*)

commented

Unfortunately https://crates.io/crates/ssi depends on older versions of some of the same libraries (e.g. k256), and because those libraries are in their 0.x series, a minor revision bump is not considered backward compatible. I've mentioned this to the ssi group because they're considering releasing 0.4, so this would be the time to make such a change -- spruceid/ssi#384

commented

The output of cargo tree --features k256,ring on the v0.3.0 branch of ssi crate includes:

├── bitvec v0.20.4                                                                                                                                                                 
│   ├── funty v1.1.0                                                                                                                                                               
│   ├── radium v0.6.2                                                                                                                                                              
│   ├── tap v1.0.1                                                                                                                                                                 
│   └── wyz v0.2.0                                                                                                                                                                 

When I add did-key = "0.1.1" to ssi/Cargo.toml, then cargo tree complains of not being able to resolve incompatible versions.

error: failed to select a version for `funty`.
    ... required by package `bitvec v0.20.2`
    ... which satisfies dependency `bitvec = "^0.20.2"` of package `elliptic-curve v0.9.12`
    ... which satisfies dependency `elliptic-curve = "^0.9.12"` of package `ecdsa v0.11.1`
    ... which satisfies dependency `ecdsa-core = "^0.11"` of package `k256 v0.8.1`
    ... which satisfies dependency `k256 = "^0.8"` of package `did-method-key v0.1.1 (/home/vdods/files/github/LedgerDomain/ssi/did-key)`
    ... which satisfies path dependency `did-method-key` of package `ssi v0.3.0 (/home/vdods/files/github/LedgerDomain/ssi)`
    ... which satisfies path dependency `ssi` of package `did-ethr v0.0.1 (/home/vdods/files/github/LedgerDomain/ssi/did-ethr)`
versions that meet the requirements `~1.1` are: 1.1.0

all possible versions conflict with previously selected packages.

  previously selected package `funty v1.2.0`
    ... which satisfies dependency `funty = "~1.2"` of package `bitvec v0.22.0`
    ... which satisfies dependency `bitvec = "^0.22"` of package `ff v0.11.0`
    ... which satisfies dependency `ff = "^0.11"` of package `bls12_381_plus v0.6.0`
    ... which satisfies dependency `bls12_381_plus = "^0.6"` of package `did-key v0.1.1`
    ... which satisfies dependency `did-key = "^0.1.1"` of package `ssi v0.3.0 (/home/vdods/files/github/LedgerDomain/ssi)`
    ... which satisfies path dependency `ssi` of package `did-ethr v0.0.1 (/home/vdods/files/github/LedgerDomain/ssi/did-ethr)`

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

It looks like the Spruce team is working on update to address this. Do you mind using the version from your branch in the meantime? I'm hesitant to support a version here that's functionally incorrect: BBS signatures != BLS signatures.

commented

Yeah, that's totally fair!