...
Meeting Topics
- Sovrin Node build
- Indy Test Automation – focus of work. GHActions work, through some blockers – likely the big ones. Nothing more this week, but back to it next week. Help on the transition of indy-node from RC to final:
- A review of the differences between the indy-node and indy-plenum "main" and "ubuntu-20.04-upgrade" branches
- Where there are things needed items in main, determine if they need to be added to the "ubuntu-20.04-upgrade" branch
- Development has continued on main and ubuntu-20.04-upgrade (branched from main) – what is missing from main that should be in ubuntu-20.04-upgrade branch?
- This is the result of the "two branch" strategy for the repos, followed by a period without maintainers watching the branches.
- Once we have the "ubuntu-20.04" branch complete, it will be become main, and we'll ignore the other branches.
- Where there are things needed items in main, determine if they need to be added to the "ubuntu-20.04-upgrade" branch
- 3rd party dependencies – such as this https://github.com/hyperledger/indy-node/issues/1786#issuecomment-1292236274 needs some help
- Other issues found by Christian Bormann
- Audit ledger is supposed to create an entry every 5 minutes, but is actually creating 3 every 5 minutes (one per ledger instead of one across ledgers). Issue – not fixed.
- Christian Bormannto open issue with the details when he has a chance.
- Concern is a large audit ledger delays catch-up.
- Issue with the timestamp recording for the domain ledger during catchup. Could cause a corruption, but unlikely. Fix has been added. Need to get to 1.13 to properly fix this.
- Need to validate that this will work on existing networks.
- More research into the real world implications
- Christian Bormannstill looking at it.
Update on indy-vdr issue with Genesis File/Node mismatch issue (indy-vdr#106) - Audit ledger is supposed to create an entry every 5 minutes, but is actually creating 3 every 5 minutes (one per ledger instead of one across ledgers). Issue – not fixed.
- indy-vdr on connecting tries to do a consensus by connecting to lots of nodes
- Triggered on Sovrin Staging Net – genesis file has 16 nodes, indy-vdr tries to connect to at least 6
- One genesis file node is active on MainNet, no longer on StagingNet – so it's response is bad.
- Don't do this! On changing network, change something...perhaps remove from the genesis file, or the IP address, or the port(s)
- If another node is slow or unresponsive, indy-vdr gives a timeout
- One genesis file node is active on MainNet, no longer on StagingNet – so it's response is bad.
- Workaround is to have an accurate genesis file – e.g. for StagingNet, add an additional genesis file
- Another app level workaround is to cache the pool state and pass that to indy-vdr (vs. the genesis file)
- Related security testing outcomes, Lynn Bendixsen - bottom line – no concerns identified.
- Sometimes nodes out, if they were part of the ones that indy-vdr is connecting to, that's a problem. Nodes from genesis file is random.
- indy-sdk behaves differently and it didn't happen: What's the difference? Can indy-vdr be changed to be more aligned with what indy-sdk is doing?
- Trying to do consistency check, testing on 4 node network – what if there is just 1 one node and trying to "steal" a node.
- Series of tests to "steal" a network or nodes.
- Unable to exploit any vulnerability in trying to find if the node is valid. Checks are necessary.
- Recommendations for genesis file updates
- GHA to create a PR to update the indy-networks repo when the genesis file changes, with a human to merge the PR.
Question from Christian today – using indy-node-container for the indy-vdr tests - In https://github.com/hyperledger/indy-vdr/tree/did-indy/ci there is a indy network being started – much better to use common indy-node-containerChristian Bormann– another issue to be created to propose this, get it on the backlog
- Deprecate the indy-sdk initiative:
- Enable shared components in all Aries Framework – notable AFJ and Aries VCX
- indy-vdr with did:indy support – how do we get that released?
- indy-vdr is using Ursa, which is using a deprecated Rust module "failure" – https://github.com/hyperledger/ursa/issues/199; CVE - very high score! Possibly not critical for us, but looks bad.
- Create a migration tool to export indy-wallet contents and load into aries-askar
- Create a "shared components" version of the Indy CLI
- New transaction types in indy-vdr – draft PR, but needs work and testing
- Indy Test Automation relies on the indy-sdk, needs to be moved to indy-sdk
- Community impact on the use of the indy-sdk – a need to migrate
- Tools on the indy-node nodes – do they use libindy? Investigation needed – Lynn Bendixsen / Wade Barnes to look at/create issue.
- Updates on the AnonCreds work that impact Indy
- Other Topics
...