The script provided for signature might be externally provided, for instance by way of ‘finalizepsbt’. Therefore the script might be ill-crafted, so don’t assume pubkeys are always 32 bytes.
Thanks to Niklas for finding this.
FIxes #29851.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
1273+ prev.vout.emplace_back(0, GetScriptForDestination(builder.GetOutput()));
1274+ curr.vin.emplace_back(COutPoint{prev.GetHash(), 0});
1275+ sig_data.tr_spenddata = builder.GetSpendData();
1276+
1277+ // SignSignature can fail but it shouldn't raise an exception (nor crash).
1278+ SignSignature(keystore, CTransaction(prev), curr, 0, SIGHASH_ALL, sig_data);
I think it would be good to check that SignSignature
fails here:
0 BOOST_CHECK(!SignSignature(keystore, CTransaction(prev), curr, 0, SIGHASH_ALL, sig_data));
The script provided for signature might be externally provided, for
instance by way of 'finalizepsbt'. Therefore the script might be
ill-crafted, so don't assume pubkeys are always 32 bytes.
Thanks to Niklas for finding this.
ACK 4d8d21320eba54571ff63931509cd515c3e20339 with a small nuance that could be tackled in a follow-up by someone else (or never).
As this was found by the RPC fuzzer, it would be nice to re-use those inputs and craft a functional test, rather than covering it on a unit test. This is because functional tests can be ported across releases with the bug fix, while unit tests might not be easy to port due to some internal changes. Plus, in the long term, unit tests require more maintenance work.