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
Certain JPEGs cause assertion failure in zune-jpeg #2230
Comments
I can confirm this problem - after update to 0.25 (which switched to to zune as default jpeg backend) I see assertion panic for several jpeg images. Looks like solution is upgrade to zune 0.5 ... For me it's quite serious problem - using library for icons creation in web server so panic is no go. |
Sorry that this bug is proving disruptive. Upstream has indicated that it'll be fixed in their next release, and we already have #2198 ready for upgrading to it. In the meantime, there isn't much more to be done on our end. You might be able to work around it using As far as using using this crate for user input on a web server, I will caution that the code hasn't been fully hardened against malicious input. Over the last few years we've used fuzzing to significantly cut down on the number of places that can trigger panics from malicious input, but that work is not yet complete. Finally, in light of some of the discussion on linked issues, I want to remind everyone to engage respectfully. These crates are all maintained by volunteers. You aren't owed a release on any particular schedule. |
@fintelia - Thanks for reply - for now I've downgraded to 0.24 - which does not have these issues. I definitely did not want to be pushy, I understand the burden of maintaining an opensource project, big thanks to all of image and zune contributors. I just wanted to stress, that jpegs, that caused panic are generally common. It was not specially crafted jpeg - I do have some collection of downloaded covers and problem was with notable fraction of these - like %5 - so just wanted to highlight the importance of the issue. |
Yeah, unfortunately that's kind of common with image files. Some specific encoder might consistently generate weird files that all fail the same way, while images produced by other encoders might never fail that way. The zune-jpeg crate was tested on a corpus of ~40,000 images but evidently it either regressed or no images like yours were included |
This happens in 0.25.1
Expected
Panic on
unwrap
Actual behaviour
Assertion failure within the jpeg decoder
Reproduction steps
Hello! I ran into this issue: etemesi254/zune-image#184 which is supposed to be fixed in 0.5.0-rc0. I've asked if it's possible to provide a 0.4 version with the assertion removed.
This is sadcomp.jpg. Uploading to github doesn't seem to have changed the behavior.
(I've had this image since 2020, I promise I didn't mess with it on purpose 😅)
The text was updated successfully, but these errors were encountered: