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
Display for NSString truncates at null bytes
#14
Comments
* Add fruity advisory for nvzqz/fruity#14 * Fix lint error * Fix lint error * Add an impact section
|
Heads up: this issue has been included in the RustSec advisory database. It will be surfaced by tools such as cargo-audit or cargo-deny from now on. Once a fix is released to crates.io, please open a pull request to update the advisory with the patched version, or file an issue on the advisory database repository. |
|
This is now fixed in release |
|
Thanks @nvzqz! The new implementation looks good and appears to resolve the issue. Also, |
|
@dylni that method is safe because the |
|
@nvzqz Sorry, I realized my original comment was wrong and edited it. You are correct that the lifetime is now sufficiently enforced. |
|
No worries. I appreciate your diligence. Things like that do get missed. |
If the user needs the string to end with e.g. two NUL, we really shouldn't stop them. `fruity` probably did this originally because their NSString truncated at null bytes, see nvzqz/fruity#14
If the user needs the string to end with e.g. two NUL, we really shouldn't stop them. `fruity` probably did this originally because their NSString truncated at null bytes, see nvzqz/fruity#14
If the user needs the string to end with e.g. two NUL, we really shouldn't stop them. `fruity` probably did this originally because their NSString truncated at null bytes, see nvzqz/fruity#14
If the user needs the string to end with e.g. two NUL, we really shouldn't stop them. `fruity` probably did this originally because their NSString truncated at null bytes, see nvzqz/fruity#14
If the user needs the string to end with e.g. two NUL, we really shouldn't stop them. `fruity` probably did this originally because their NSString truncated at null bytes, see nvzqz/fruity#14
If the user needs the string to end with e.g. two NUL, we really shouldn't stop them. `fruity` probably did this originally because their NSString truncated at null bytes, see nvzqz/fruity#14
If the user needs the string to end with e.g. two NUL, we really shouldn't stop them. `fruity` probably did this originally because their NSString truncated at null bytes, see nvzqz/fruity#14
This issue was originally reported privately, but I thought I should create an issue to inform others about it, as it has not yet been fixed.
The implementation of
DisplayforNSStringtruncates at null bytes, since it usesCStr::from_ptr. It should be possible to use[NSString lengthOfBytesUsingEncoding:]and[NSString UTF8String]instead to create the complete string.Example:
That example only prints the string "null". Since
ToString::to_stringusesDisplayto create strings, it has the same issue.NSString::to_strandNSString::to_str_with_nullalso have the same issue.If you believe this is a valid issue, I encourage you to file a security advisory at https://github.com/rustsec/advisory-db, including a patch version if it is possible to release within two weeks.
Thank you for your work on this crate. Creating a security advisory is not meant to be anything other than a way to provide information to other users.
The text was updated successfully, but these errors were encountered: