-
Notifications
You must be signed in to change notification settings - Fork 226
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
Evaluate flate2 #143
Comments
I'm now working my way through libflate, reporting sometimes and fixing the issues I discover: I couldn't get any bugs out of miniz_oxide (the Rust backend for flate2) with a fuzzer, including when fuzzing with libdiffuzz. I have to admit that reasoning about the unsafety in miniz_oxide is beyond my abilities, but it doesn't look very reassuring. Issues like Frommi/miniz_oxide#14 also don't instill confidence. I can vouch for the safety of https://github.com/image-rs/inflate because I've purged all but one unsafe blocks in it, and then found and fixed the bug in the remaining unsafe block together with the maintainer. But last time I checked it was even slower than libflate. |
I'm done cleansing Also, I've since discovered a heap buffer overflow in miniz_oxide and likely also miniz. There is still a lot of unsafe code in them that I was unable to audit, so I would advise against using them if safety is a concern. |
Nice! Than I will force the minimum |
I believe this issue should be revisited. The Rust backend for flate2 called miniz_oxide is now 100% safe and forbids unsafe code. It is also 2.5x faster on decompression than libflate. There is still some unsafety in flate2, so I'd suggest using miniz_oxide directly. This would improve performance, provide compiler-guaranteed safety and reduce the number of dependencies. |
Thanks. I will try it out. |
I've switched to |
Looks like
flate2
is more safe thanlibflate
.The text was updated successfully, but these errors were encountered: