Closed dandanlen closed 1 year ago
While I think the original intent was to only expose trait Key
to prevent misusing SecretKey
(i.e. using it without zeroize), I believe it isn't sufficient to prevent misuse and in reality handling the secret keys properly is way beyond the purpose of this crate.
The secp256k1::SecretKey
documentation also mentions that keys should be handled and SecretKey::non_secure_erase
method is exposed, linking to zeroize
crate for more info, hence I'm willing to merge the PR to improve usability.
Thanks for this - I fixed the formatting issue that was blocking the merge...
secp256k1::SecretKey
is required in order to use the offline signing functionality but at present it's not re-exported. This means anyone who want to use the signing functionality has to add an explicit dependency onsecp256k1
, and has to keep it in-sync with the version inweb3
.This PR changes the re-export of the
secp256k1::SecretKey
frompub(crate)
topub
so that is can be accessed through theweb3::signing
module, removing the requirement for an explicit dependency on secp256k1.