Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corrects type of sign and signAsync #102

Merged
merged 1 commit into from
Apr 29, 2023
Merged

Conversation

MicahZoltu
Copy link
Contributor

The only place that priv is used in signAsync and sign is when it is passed to prepSig. The only place priv is used in prepSig is when it is passed to toPriv. toPriv takes a PrivKey, so that means prepSig, sign, and signAsync can also take a PrivKey.

Functionally, this means that bigint is now allowed as a private key. This will make it so users who are storing private keys in memory as bigints will not have to first convert to hex.

Node: Currently if you naively convert your bigint private key to hex using 0x${privateKey.toString(16)} this library will throw an error complaining about the hex for the private key being the wrong length. Arguably this library should accept an odd length hex value for the private key, but in my case just accepting bigints directly would fix the issue and allowing odd length hex strings would require an actual code change rather than just a type change.

The only place that `priv` is used in `signAsync` and `sign` is when it is passed to `prepSig`.  The only place `priv` is used in `prepSig` is when it is passed to `toPriv`.  `toPriv` takes a `PrivKey`, so that means `prepSig`, `sign`, and `signAsync` can also take a `PrivKey`.

Functionally, this means that `bigint` is now allowed as a private key.  This will make it so users who are storing private keys in memory as bigints will not have to first convert to hex.

Node: Currently if you naively convert your bigint private key to hex using `0x${privateKey.toString(16)}` this library will throw an error complaining about the hex for the private key being the wrong length.  Arguably this library should accept an odd length hex value for the private key, but in my case just accepting bigints directly would fix the issue and allowing odd length hex strings would require an actual code change rather than just a type change.
@paulmillr paulmillr merged commit 0fb0d8e into paulmillr:main Apr 29, 2023
@MicahZoltu MicahZoltu deleted the patch-2 branch April 29, 2023 07:21
@MicahZoltu
Copy link
Contributor Author

What is the release process like for this project? I know it was audited, and I'm not sure if changes to type info would require a new audit or if this can be done as a patch release before the next major release?

@paulmillr
Copy link
Owner

release schedule is limited once per 1-2 months unless urgent. that's mostly it. 2.0.1 will follow.

@paulmillr
Copy link
Owner

also 2.0 wasn't audited, noble-curves were

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants