Use audited dependencies
paulmillr opened this issue · comments
- @stablelib/ed25519, @stablelib/x25519, elliptic - replace with noble-curves
- @stablelib/random, @stablelib/sha256, js-sha3 - replace with noble-hashes
- bech32 - replace with scure-base
- @stablelib/xchacha20poly1305, canonicalize, did-resolver, multiformats, uint8arrays will remain
Wanna me send a PR?
Not a maintainer, but I think it would be really nice to use audited packages.
I have one question though. Do these libs work on React Native?
As there is overlap in maintainers between Veramo and this package and one of the requirements of Veramo is that it also has to run on RN, this package also needs to run on RN.
If it does not it would break certain apps, like our wallet.
Yes they do
Cool
@mirceanis What do you think. If you ask me it would be great to have audited packages for these core functionalities needed in this lib
@paulmillr a PR would be highly appreciated! 🙏
https://discord.com/channels/878293684620234752/933661591264702474/1081295858714296491
The discord link refers to this server: https://discord.gg/U5SCRnNFuS
I'm in favor of a replacement.
I would have liked to move forward with #170, which aims to refactor this library to allow folks to bring their own crypto implementations instead of us bundling things in, but since I haven't had any time for that it makes more sense to do what you suggest.
I see you have ES256K, ES256 signers. How should this rewrite behave? Should I simply replace elliptic with noble in these files, or should I create new signers?
Great minds think alike: #280
Have just noticed this thread, otherwise would ping you pals first before doing any code.
🎉 This issue has been resolved in version 7.0.0 🎉
The release is available on:
Your semantic-release bot 📦🚀
Hey @ukstv , this is wonderful, thank you for doing this!
I was wondering if you're able to do the same for the did-provider-key lib, which still has the @transmute/... dependenceis and they marked as unstable releases. There have been discussions of replacing those as well. That would be amazing!
@inevolin The package you mentioned is not directly used by Ceramic ecosystem AFAIK, so I would like to politely refuse the invitation.
What I could propose instead, is maybe you could depend on key-did-provider-ed25519 or key-did-provider-secp256k1 which are cared for. As soon as paulmillr/noble-curves#32 gets merged, we could fully migrate to noble-crypto and leverage its speed and dependability there. That would transitively apply to your package suite as well.
interesting! thank you