No Project Lifecycle Badge found in your readme!

Hello! I scanned your readme and could not find a project lifecycle badge. A project lifecycle badge will provide contributors to your project as well as other stakeholders (platform services, executive) insight into the lifecycle of your repository.

What is a Project Lifecycle Badge?

It is a simple image that neatly describes your project's stage in its lifecycle. More information can be found in the project lifecycle badges documentation.

What do I need to do?

I suggest you make a PR into your README.md and add a project lifecycle badge near the top where it is easy for your users to pick it up :). Once it is merged feel free to close this issue. I will not open up a new one :)

Condition 1

Running a cargo check on a project with an indy-credx 0.3.0 dependency will fail to compile due to mismatching types.

Currently this yields 13 errors all similar to the following:

error[E0308]: mismatched types
   --> /Users/gmulhearne/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-credx-0.3.0/src/services/issuer.rs:164:9
    |
164 |         &origin_did,
    |         ^^^^^^^^^^^ expected struct `indy_data_types::did::DidValue`, found `&indy_utils::did::DidValue`
    |
    = note: expected reference `&indy_data_types::did::DidValue`
               found reference `&&indy_utils::did::DidValue`

error[E0599]: no method named `to_unqualified` found for struct `indy_data_types::RevocationRegistryId` in the current scope
   --> /Users/gmulhearne/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-credx-0.3.0/src/services/issuer.rs:384:59
    |
384 |                 Some(ref _method_name) => Some(reg_reg_id.to_unqualified()),
    |                                                           ^^^^^^^^^^^^^^ method not found in `indy_data_types::RevocationRegistryId`

I believe this has to do with different versions of indy-utils being resolved by credx.

Here's the cargo tree:

└── indy-credx v0.3.0
    ├── indy-data-types v0.5.1
    │   ├── indy-utils v0.5.0
    │   │   ├── indy-wql v0.4.0
    ├── indy-utils v0.4.0
    │   ├── indy-wql v0.4.0 (*)

Since credx 0.3.0 depends on data-types ^0.5.0, and on utils ^0.4.0, a conflict happens when data-types 0.5.1 is used, as the update from data-types 0.5.0 -> 0.5.1 involved bumping the indy-utils dependency from 0.4.0 -> 0.5.0.

Perhaps that indy-data-types version bump should not have been a minor patch update?

You can see that when you force indy-data-types = "=0.5.0", the dependency resolution for indy-utils versions is fine:

├── indy-credx v0.3.0
│   ├── indy-data-types v0.5.0
│   │   ├── indy-utils v0.4.0
│   │   │   ├── indy-wql v0.4.0
│   ├── indy-utils v0.4.0 (*)
└── indy-data-types v0.5.0 (*)

Condition 2

Running cargo check on a project with the latest indy-credx 0.3.4 dependency, along side an ursa ^0.3.7 dependency will cause a similar mismatch of indy-utils versions. The tree can be seen below:

├── indy-credx v0.3.1
│   ├── indy-data-types v0.5.0
│   │   ├── indy-utils v0.4.0
│   │   │   ├── indy-wql v0.4.0
│   │   ├── ursa v0.3.7
│   ├── indy-utils v0.5.0
│   │   ├── indy-wql v0.4.0 (*)
└── ursa v0.3.7 (*)

This is because data-types 0.5.1 depends STRICTLY on ursa =0.3.6, so credx is forced to use data-types 0.5.0 (which allows ursa 0.3.7) whilst still using indy-utils directly at version 0.5.0

Related to similar issue with indy-vdr: hyperledger/indy-vdr#103

I have tried to install aires-cloudagent-python on Raspberry Pi 4 (ARM Cortex-A53 processor) by manually building libraries for aries-askar indy-credx and indy-vdr. For indy-vdr and aries-askar I do not faced any problem. For indy-credx the compilation is successful.
But when I try to release new credentials or a new scheme I receive an error from the bindings.py wrapper script

Clearly, the exception is caused by the method do_call(), which receives as a response from the execution of credx_set_default_logger the value 4294967296 instead of receiving 0.

Moreover, I noticed by modifying the code of the function and commenting the row 463 lib_fn.restype = c_int64, the return of credx_set_default_logger is 0; but since the restype must be set in that way everything else crash.

TL;DR

Topics greatly improve the discoverability of repos; please add the short code from the table below to the topics of your repo so that ministries can use GitHub's search to find out what repos belong to them and other visitors can find useful content (and reuse it!).

Why Topic

In short order we'll add our 800th repo. This large number clearly demonstrates the success of using GitHub and our Open Source initiative. This huge success means its critical that we work to make our content as discoverable as possible; Through discoverability, we promote code reuse across a large decentralized organization like the Government of British Columbia as well as allow ministries to find the repos they own.

What to do

Below is a table of abbreviation a.k.a short codes for each ministry; they're the ones used in all @gov.bc.ca email addresses. Please add the short codes of the ministry or organization that "owns" this repo as a topic.

That's in, you're done!!!

How to use

Once topics are added, you can use them in GitHub's search. For example, enter something like org:bcgov topic:citz to find all the repos that belong to Citizens' Services. You can refine this search by adding key words specific to a subject you're interested in. To learn more about searching through repos check out GitHub's doc on searching.

Pro Tip 🤓

• If your org is not in the list below, or the table contains errors, please create an issue here.

• While you're doing this, add additional topics that would help someone searching for "something". These can be the language used javascript or R; something like opendata or data for data only repos; or any other key words that are useful.

• Add a meaningful description to your repo. This is hugely valuable to people looking through our repositories.

• If your application is live, add the production URL.

Ministry Short Codes

NOTE See an error or omission? Please create an issue here to get it remedied.

This is the reason for the error hyperledger/aries-cloudagent-python#2036

The problem is here:
https://github.com/hyperledger/indy-shared-rs/blob/v0.3.1/wrappers/python/indy_credx/types.py#L457-L464

The RevocationRegistry created at L459 will be deallocated outside the for loop, but it's handle entry.handle at L462 should be retained by the reg_entries list.
This would work if the RevocationEntry at L461 is not Structure type. RevocationEntry subclasses Structure of ctypes and this makes entry.handle deallocated before bindings.verify_presentation() starts.
I could make it work by retaining the RevocationRegistry created at L459 in a dummy list to prevent deallocation, which also prevents the deallocation of its handle.

You may wonder why it works when there is only one revocation entry. I suppose it's dependent on the GC behavior of python.
I created a sample code to see this issue.

from ctypes import c_int64, Structure, c_char_p

class Age(c_int64):
    def __del__(self):
        print(f"Age: delete called for {self.value}")

class Applicant:
    def __init__(self, name, age = None):
        self.name = name
        if not age:
            age = Age(0)
        self.age = age

    def __del__(self):
        print(f"Applicant: delete called for {self.name}")

class Candidate(Structure):
    _fields_ = [("name", c_char_p), ("age", Age)]

    @classmethod
    def create(
        cls,
        name,
        age,
    ):
        return Candidate(name=c_char_p(name.encode("utf-8")), age=age)

def print_candidates(applicants):
    candidates = []
    for applicant in applicants:
        if not isinstance(applicant, Applicant):
            applicant = Applicant(applicant)
        print("== appending candidate: ", applicant.name)
        candidates.append(Candidate.create(applicant.name, applicant.age))  # <-- applicant.age is not retained by this because Candidate is a Struct.

    print("== print candidates ==")
    for candidate in candidates:
        print(candidate.name)

print("== print multiple candidates ==")
applicants = [
    "Alice",
    Applicant("Bob", Age(30)),
]

print_candidates(applicants)

print("== print a single candidate ==")
applicants = [
    "Alice",
]

print_candidates(applicants)

You can find that the Age instance, which corresponds to ObjectHandle, is deallocated before printing the candidates when there is more than one entry.

TL;DR

Topics greatly improve the discoverability of repos; please add the short code from the table below to the topics of your repo so that ministries can use GitHub's search to find out what repos belong to them and other visitors can find useful content (and reuse it!).

Why Topic

In short order we'll add our 800th repo. This large number clearly demonstrates the success of using GitHub and our Open Source initiative. This huge success means its critical that we work to make our content as discoverable as possible; Through discoverability, we promote code reuse across a large decentralized organization like the Government of British Columbia as well as allow ministries to find the repos they own.

What to do

Below is a table of abbreviation a.k.a short codes for each ministry; they're the ones used in all @gov.bc.ca email addresses. Please add the short codes of the ministry or organization that "owns" this repo as a topic.

That's in, you're done!!!

How to use

Once topics are added, you can use them in GitHub's search. For example, enter something like org:bcgov topic:citz to find all the repos that belong to Citizens' Services. You can refine this search by adding key words specific to a subject you're interested in. To learn more about searching through repos check out GitHub's doc on searching.

Pro Tip 🤓

• If your org is not in the list below, or the table contains errors, please create an issue here.

• While you're doing this, add additional topics that would help someone searching for "something". These can be the language used javascript or R; something like opendata or data for data only repos; or any other key words that are useful.

• Add a meaningful description to your repo. This is hugely valuable to people looking through our repositories.

• If your application is live, add the production URL.

Ministry Short Codes

NOTE See an error or omission? Please create an issue here to get it remedied.

Please update the implementation of CredX to add support for identifiers in objects either published on ledgers (DIDs, SCHEMA, CRED_DEF, REV_REG and REV_REG_ENTRY), or shared between participants (OFFER_CREDENTIAL, REQUEST_CREDENTIAL, ISSUE_CREDENTIAL, REQUEST_PROOF and PROOF).

As part of that -- please discuss what that will take. My thought is that it should be relatively easy for the identifiers to be processed -- e.g. recognize which format is being used and process it accordingly. More challenging (I think) is that the identifiers could now contain extra information -- what ledger is to be used. How does that extra information get shared back to the entity that needs it? For example,

• If the an old format ID is used, we don't know what ledger the referenced object is on. Do we use existing multi-ledger code for that?
• If a new format ID is used, we know exactly the ledger. How does that get used? Is that needed/used by CredX?

I suspect that what we need to do is update the Aries RFC 0592 Indy Attachments to add the format of the new identifiers and where they might be used.

FYI the formats being added are:

1. Extending where ever a DID is referenced in the existing identifiers with the did:indy:<namespace>: prefix.
2. Use the DID path format, such as for a SCHEMA, the URL is: did:indy:sovrin:F72i3Y3Q4i466efjYJYCHM/anoncreds/v0/SCHEMA/npdb/4.3.4

See Error here: https://github.com/hyperledger/indy-shared-rs/actions/runs/7905468437/job/21578169242?pr=46

I am trying to build indy-credx for Android and iOS, but since indy-data-types uses openssl it is becoming rather complicated. I noticed that openssl is optional and when I look trough the codebase it does not even seem used. These seem to be the references to openssl, but I could not find any place where the library is actually used.

indy-utils/src/hash.rs:    /// See `openssl::hash::Hasher::update` for more information.
indy-data-types/Cargo.toml:vendored = ["openssl", "openssl/vendored"]
indy-data-types/Cargo.toml:openssl = { version = "0.10", optional = true }

What are the implications if openssl is not used and what is it actually used for here?

In commit #2502647 lib_name was changed to lib_path in two places in wrappers/python/indy_credx/bindings.py. In the first instance, the code is preceded by:

lib_path = find_library(lib_name)
if not lib_path:

Since the if statement tests for no library returned from find_library, the value of lib_path will always be None within the if statement, resulting in the library name in the message always being None:

indy_credx.error.CredxError: Library not found in path: None

Note that in reference to the other place where lib_name was changed to lib_path in CredxErrorCode.WRAPPER, f"Error loading library: {lib_path}" -- there is the same code in indy-vdr/wrappers/python/indy_vdr/bindings.py. If the change is appropriate in this bindings.py, the same change could be made in the bindings.py file in the Indy VDR repository also.

Not to be included in CredX, but just a standalone script to convert an AnonCreds verifiable credential to the W3C VC Data Model. This presentation slide includes a proposed mapping of the data elements. If we can get a script, we can tweak it from there for a good mapping. For now, please include the encoded values in the proof -- we can talk about whether they should be left off.

For a presentation, I suggest that we again create a W3C VC Data Model verifiable credential (not a VP) and that in the CredentialSubject go an arrays for the referants (name, names), predicates, unrevealed attributes, and self-attested attributes. Then in the proof section, pretty much everything else. Again, having a working script is the first step, and then we can iterate to get it right.

As well as the AnonCreds to W3C Verifiable Credential scripts, reverse ones would be good as well.

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 [email protected] 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 [email protected] 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

As per Andrew Whitehead from a discord chat:

It looks like the hard link is a side effect of the tempfile library that indy-credx is currently using, which also seems to have significant dependencies. Probably a better plan to switch to 'temp-file' and rename or copy the result. We don't use the database here mainly because the tails file can be quite large, and saving it could exceed the transfer buffer with the database. Especially since we don't set a hard limit on the number of credentials

Code is here: https://github.com/hyperledger/indy-shared-rs/blob/main/indy-credx/src/services/tails.rs#L152

Trace is here - ACA-Py hangs:

600141 lseek(31</home/indy/.indy_client/tails/.hopper/.tmplQSjIq>, 0, SEEK_CUR) = 2690 3600141 link("/home/indy/.indy_client/tails/.hopper/.tmplQSjIq", "/home/indy/.in dy_client/tails/.hopper/B5a1pjY6VxPS1wdnNM9RHVUKzeTJq9yjofoDqGRqUBrw" <unfinishe d ...> 3587464 <... epoll_wait resumed> [], 4, 47) = 0 3587464 epoll_wait(4<anon_inode:[eventpoll]>, [], 4, 0) = 0 3587464 getpid() = 3587464 3587464 epoll_wait(4<anon_inode:[eventpoll]>, <unfinished ...> 3600141 <... link resumed> ) = -1 EOPNOTSUPP (Operation not supported