Page History

...

• Future calls:
  • Cancel the call September 30 for IIW
  • Cancel the call October 14
• Ubuntu 18.04 on Indy Node
  • Want to support 18.04 and 16.04 simultaneously (until 20.04 comes out).
  • Cam has a PR, and is working on incorporating feedback.
• Security reports
• Ursa and AMCL:  Discussed in the Ursa call (August 21)Ursa will provide an AMCL crate, but no decision timeline yet.
• fuzzing libindy https://github.com/AxelNennker/indy-sdk/tree/fuzzing/
  `cargo +nightly fuzz run fuzz_target_1 -- -only_ascii=1`
  Worried about unsafe code in libindy
  ```
  ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ find src -name \*\.rs -exec fgrep unsafe {} \; | wc -l
  61
  ```

  Future Calls

  • • Should be testing deeper: can we pass unexpected values across the unsafe boundary? Should do more fuzzing. Would make a good internship.
    • It looks bad. Some unsafe code is required to have a C-API. FFI support doesn't really help.
    • Mike wants to review the 61 cases and figure out if they are justified.
    Non-secrets in the Indy Wallet
    • Cam is working on pluggable crypto. They wallet shouldn't decide what encryption you should be using.
    • Use cases where we would want to move keys between wallets
      • Moving the link secret / credential data from one device to another (synchronized storage).
      • Debug use cases
      • Richard's hit other uses cases that were better solved with DID Doc,  pre-signing, signing API.
    • Work-around with the web-crypto API
  • Fully Qualified DID support in Indy SDK
  • Define pull request review process for Indy Node.
    • Should define the process, including how we handle exceptions (emergency fixes shouldn't be blocked, but would require notification)
    • What is important in a good review?
    • If a review must be skipped, should note it in the Git commit message.
  • : Evernym demo video.
  • Handling pull requests.
    • How to handle old pull requests that failed DCO Checks? Close?
      • Closing the PR doesn't get rid of the work. The author can reopen at any time.
    • How to handle pull requests for IOS / Swift wrappers? Close and encourage the move to Aries?
    • How to handle pull requests for LibVCX? Deprecate?
    • Close PR https://github.com/hyperledger/indy-sdk/pull/1048 as something that will be replaced by the advanced schema work?
    • HIPE pull requests: https://github.com/hyperledger/indy-hipe/pulls
    • Kyle will continue reviewing PRs, but does not want to be a bottleneck slowing down the process.
    • Would be best to put in a comment notifying the author of our intention to close in 1-4 weeks.

  Future Calls

  • Non-secrets in the Indy Wallet
    • Cam is working on pluggable crypto. They wallet shouldn't decide what encryption you should be using.
    • Use cases where we would want to move keys between wallets
      • Moving the link secret / credential data from one device to another (synchronized storage).
      • Debug use cases
      • Richard's hit other uses cases that were better solved with DID Doc,  pre-signing, signing API.
    • Work-around with the web-crypto API
  • Define pull request review process for Indy Node.
    • Should define the process, including how we handle exceptions (emergency fixes shouldn't be blocked, but would require notification)
    • What is important in a good review?
    • If a review must be skipped, should note it in the Git commit message.

  Action items

  •  HIPE #138, Issue #144 (Ken and Brent)
    
    • Create a PR for changing status to ACCEPTED
    • Check for an Aries RFC
  •  PR to RFC #0019 to compare pack/upack to msgpack (Sergey)
  •  Richard and Sergey will close old pull requests with a descriptive comment.
  •  Mike wants to review the 61 cases of "unsafe" libindy calls and figure out if they are justified.

  Call Recording

  Call was not recorded due to a problem with Zoom permissions.