Certain JPEGs cause assertion failure in zune-jpeg about image HOT 6 CLOSED

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 catch_unwind though.

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.

from image.

zune-jpeg has several functional regressions (in the form of full-blown panics) that present when decoding jpegs in image 0.25 that the zune author has patched in the api-incompatible 0.5 release but has thus far not responded to requests for backports for 0.4 that image uses (one of these is a one-line patch to the current 0.4 zune-jpeg release).

Could there be some sort of discussion/agreement between the authors of image and zune to get backported fixes for critical issues like this that effectively completely block users from upgrading to the current image version or force them to depend on multiple versions of image (and its transitive dependencies) to work around semver issues?

Otherwise, is there any consideration for using a patched/forkedf version of zune-jpeg for a new image point release until a release with full zune-jpeg 0.5 support is issued?

image is, at this point, a foundational crate in the rust ecosystem and it is really sad to see a major release completely broken by faulty assertions in a core transitive dependency that have already been patched upstream.

from image.

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.
zune has this issue etemesi254/zune-image#184

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.

from image.

@fintelia - Thanks for reply - for now I've downgraded to 0.24 - which does not have these issues.
Actually hyper or tokio is using catch unwind, so it only kills one of tokio worker threads (which I believe is then replaced), but anyhow panic is no good.

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.

from image.

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

from image.

If you are unhappy with this crate, you are welcome to a full refund.

I'm going to close this issue because the bug is in a different crate and the discussion here is no longer constructive

from image.