Repository navigation
doc: fix msg argument description of nonce function typedefs - #1985
amartya1523 wants to merge 2 commits into
Conversation
Both nonce function typedefs described the msg argument as the message "being verified", but nonce functions are only ever invoked by the signing functions (secp256k1_ecdsa_sign, secp256k1_ecdsa_sign_recoverable and secp256k1_schnorrsig_sign_*).
The hardened nonce function docs claimed msg is NULL if and only if msglen is 0. secp256k1_schnorrsig_sign_custom only requires that msg is non-NULL when msglen is non-zero and hands msg through to the nonce function unchanged, so a caller signing an empty message may pass either NULL or a non-NULL pointer. Use the same wording as sign_custom.
Nice catch, ACK.
Hm, I think this is a genuine bug. There's a non-zero probability that there's a custom nonce function out there that relies on the promise and just hasn't been called with an empty message so far. So I tend to think that we should err on the safe side here and rather change the semantics to what the API promised, i.e., add an |
The docs for
secp256k1_nonce_functionandsecp256k1_nonce_function_hardenedboth describe the message argument as the one "being verified". Nonce functions are only ever called from the signing functions, so the first commit changes this to "being signed".The hardened nonce function docs also say
msgis NULL if and only ifmsglenis 0. That is stricter than whatsecp256k1_schnorrsig_sign_customenforces: it only checksmsg != NULL || msglen == 0and passesmsgthrough to the nonce function unchanged, so a custom nonce function can see a non-NULLmsgwithmsglen == 0. The second commit uses the same "Can only be NULL if msglen is 0" wording thatsign_customalready has.