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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
