Bug#582417: libjpeg non issues with D_MAX_BLOCKS_IN_MCU.
block 582417 by 582522
affects 582522 src:ghostscript
thanks
According to http://www.ghostscript.com/pipermail/gs-code-review/2002-March/002275.html
we could refuse non standard jpeg encoding.
I am tenting to close theses bugs
>The second issue is the infamous D_MAX_BLOCKS_IN_MCU. The
>Ghostscript makefiles contain a rather histrionic warning about using
>shared libraries, due to the fact that they probably use the default
>value for D_MAX_BLOCKS_IN_MCU. I've done some digging into the issue,
>and believe I have gotten to the bottom of it. Let this email stand
>as a definitive position on the matter.
>
> First, I have no doubt that at one time there were files in the
>wild that exceeded the JPEG standard for the number of blocks in the
>MCU. In fact, Adobe's tech note 5116 suggests that Adobe did come
>across such implementations in their own interoperability testing
>in 1991. This tech note also states that Adobe's implementation, at
>least in some cases, will tolerate such out-of-spec JPEG streams.
>
> That said, the PRLM3 states quite straightforwardly that the number
> of blocks in the MCU must not exceed 10. The PRLM2 contains the same
> condition, but attributes it to "the JPEG-proposed standard". Thus,
> I believe that any PostScript file containing a non-compliant JPEG
> stream can safely be considered invalid.
> How likely are we to run across such invalid files? A note from Tom
> Lane (author of libjpeg) states that he's never seen such a file, nor
> has he recieved a bug report from anybody about the MCU issue:
> http://remotesensing.org/lists/libtiff_archive/msg00355.html
>
> Thus, I conclude that the chance of ordinary users running across a
>problem with such files is nil. Linking with the standard libjpeg
>should be quite safe. The attached patch to the configure script does
>this by default when the local jpeg directory is not present. When a
>local copy is present, the D_MAX_BLOCKS_IN_MCU patch is applied as
>before.
Reply to: