Giters

hyperledger-archives / ursa

Hyperledger Ursa (a shared cryptographic library) has moved to end-of-life status, with the components of Ursa still in use moved to their relevant Hyperledger projects (AnonCreds, Indy, Aries and Iroha).

Home Page:https://wiki.hyperledger.org/display/ursa

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

New Roadmap for Ursa

appetrosyan opened this issue · comments

commented

After several meetings and deliberation with @hartm et al, we settled on the following interim plan for the version 1.0

  • Update all dependencies, handling semver incompatibilities. (#225, TBD)
  • Replace fail with anyhow and std::error::Error-based workflows.
  • (Optional) only if easy, provisions for no_std.
  • (Optional) Provisions for plugging into miette and more informative error handling projects
  • Removal of feature gates for optional components. LTO is much better at eliminating unused code. The shared object produced must always include every algorithm.
  • Plugin system, such that algorithms are fully self-contained crates. This allows depending on these crates directly for faster compile times, simplifies feature testing, and ensures that algorithms are sufficiently decoupled.
  • Refactoring + linting + CI improvements.
  • CD for multiple packages and architectures. Consider using Aries runners for Apple silicon (aarch64 with x86 extensions, without SVE).
  • extern C, WASM, node, Python (PYO3) and Java interop.
commented

@mikelodder7 I don't want to break the codebase too much, so I would appreciate your input before I begin executing on this plan, particularly in relation to feature gates.

commented

Not sure if this fits at the level you are talking, but CI that produces artifacts to enable creating container images targetting multiple architectures — including ARM — would be helpful. A CI that enables a trivial change to automatically produce new release artifacts is important.

commented

This proposal is similar to the one I have in mind. Maybe it doesn't need to be here, but a provision for language wrappers like c_ffi, wasm, node, python, and java as needed. Not sure if we need no_std having done a lot of it myself. The no_std rule should be if it doesn't complicate things then fine do it, otherwise it should be optional.

commented

@swcurran not sure those artifacts are helpful except in the language wrapper case. Also if we're separating primitives individually, and you want a single library that only contains what you need, that requires a separate CI per configuration. Something to keep in mind.

commented

I've updated the roadmap with the proposed tasks. We should be able to get these done relatively soon.