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

String descriptors can panic on to_string #554

Open
apoelstra opened this issue Jun 11, 2023 · 3 comments
Open

String descriptors can panic on to_string #554

apoelstra opened this issue Jun 11, 2023 · 3 comments

Comments

@apoelstra
Copy link
Member

If you have a descriptor with String keys, and you parse one with a key outside of the checksum alphabet, desc_checksum will fail, leading to returning an error from Display::fmt, which apparently causes a panic in .to_string().

I'm not sure why we haven't seen this before but when fuzzing locally it now shows up quickly on the roundtrip_descriptor fuzztest. For example you can give it the test vector

do_test("pkh(\u{16})".as_bytes());

I'm unsure what the best plan of action here ... String descriptors aren't standardized, so I guess we can just make something up. The two ideas that come to mind are:

  • Enforce, when parsing descriptors, that every character lands in the checksum alphabet (or at least, is ASCII-printable, which I think might be the same thing)
  • When computing checksums, skip invalid characters or replace them with x or something
  • Keep the existing behavior (though then we'd need to tweak our fuzztests somehow)

Also affects elements-miniscript.

@Harshil-Jani
Copy link
Contributor

Hey @apoelstra Do we need escape characters (or in general non printable ASCII characters) in a descriptor string strictly for fuzztests or in any other parts? If not then I would love to go ahead for 1st way. If it is required then the 2nd and finally to avoid changing fuzztests.

@apoelstra
Copy link
Member Author

No, escape characters are not required in any contexts that I'm aware of. I don't think we have tests for such characters and if we did, it would be fine to drop them if we were to forbid the behavior.

@Harshil-Jani
Copy link
Contributor

Ah, I see this being already solved with 6b76997

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

No branches or pull requests

2 participants