Bug#582417: libjpeg8: Please provide variant compiled with #define D_MAX_BLOCKS_IN_MCU 64

[Jonathan Nieder <jrnieder@gmail.com>]

Bill Allombert wrote:

> Honestly, unless you provide evidence that PS files that include invalid
> jpeg-encoded data are still in use, I am not going to include two new packages
> to support non-standard compliant data in Debian, and in any case, I doubt the
> FTP master would let me. 

Makes sense.  Currently ghostscript/README.Debian says:

	GPL Ghostscript is linked against the shared IJG JPEG library (not a
	statically linked local copy).  Some valid PostScript and PDF files will
	fail to parse due to some (old, presumably?) Adobe interpreters
	violating the JPEG standard.  More info at [bug#582521].

	[bug#582521]: <http://bugs.debian.org/582521>

http://www.ghostscript.com/pipermail/gs-code-review/2002-March/002275.html
tells a slightly different story:

	   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.

So I do not even think that there are old Adobe interpreters involved
(despite what jpeglib.h says).  Would it be enough to say something
like this?

	On Debian systems, ghostscript is linked against the shared
	IJG JPEG library, instead of using the patched local copy
	bundled with the ghostscript source.  The two versions of
	the library behave identically except in two respects, both
	concerning invalid JPEG streams:

	- The bundled libjpeg fakes a valid component id when JPEG
	  streams include an SOF or SOS marker whose component
	  identifiers are not all distinct (see the description of
	  C_i in B.2.2 of the JPEG spec).  The shared IJG JPEG
	  library produces artifacts (e.g., stripes) when presented
	  with such component ids.

	  http://bugs.ghostscript.com/show_bug.cgi?id=686980

	- The bundled libjpeg is configured to accept up to 64 blocks
	  per MCU, instead of the limit of 10 blocks per MCU described
	  in the Postscript reference manual and JPEG standard.
	  According to lore and Adobe's tech note 5116, in 1991 Adobe
	  came across some files in the wild exceeding the standard
	  for blocks per MCU, and Adobe's implementation would
	  sometimes accept such streams.

	If you come across a file triggering either of these
	conditions, please let us know by reporting a bug against
	the ghostscript package.