rpms/libtiff
7
0
Fork 0
Code Issues Pull Requests Releases Activity

Update to libtiff 3.9.5

Browse Source
This commit is contained in:
Tom Lane 2011-04-12 23:00:08 -04:00
parent 0224c9c3f8
commit 2444d4596f
16 changed files with 9 additions and 523 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@ -1 +1 @@
tiff-3.9.4.tar.gz
/tiff-3.9.5.tar.gz

21
libtiff-3samples.patch
View File

@ -1,21 +0,0 @@
Patch for bug #603081: failure to guard against bogus SamplesPerPixel
when converting a YCbCr image to RGB.
This patch duplicates into PickContigCase() a safety check that already
existed in PickSeparateCase().
Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2216
diff -Naur tiff-3.9.2.orig/libtiff/tif_getimage.c tiff-3.9.2/libtiff/tif_getimage.c
--- tiff-3.9.2.orig/libtiff/tif_getimage.c 2009-08-30 12:21:46.000000000 -0400
+++ tiff-3.9.2/libtiff/tif_getimage.c 2010-06-11 12:06:47.000000000 -0400
@@ -2397,7 +2397,7 @@
}
break;
case PHOTOMETRIC_YCBCR:
- if (img->bitspersample == 8)
+ if ((img->bitspersample==8) && (img->samplesperpixel==3))
{
if (initYCbCrConversion(img)!=0)
{

27
libtiff-CVE-2011-0192.patch
View File

@ -1,27 +0,0 @@
Protect against a fax VL(n) codeword commanding a move left. Without
this, a malicious input file can generate an indefinitely large series
of runs without a0 ever reaching the right margin, thus overrunning
our buffer of run lengths. Per CVE-2011-0192. This is a modified
version of a patch proposed by Drew Yao of Apple Product Security.
It adds an unexpected() report, and disallows the equality case except
for the first run of a line, since emitting a run without increasing a0
still allows buffer overrun. (We have to allow it for the first run to
cover the case of encoding a zero-length run at start of line using VL.)
diff -Naur tiff-3.9.4.orig/libtiff/tif_fax3.h tiff-3.9.4/libtiff/tif_fax3.h
--- tiff-3.9.4.orig/libtiff/tif_fax3.h 2010-06-08 14:50:42.000000000 -0400
+++ tiff-3.9.4/libtiff/tif_fax3.h 2011-03-10 12:11:20.850839162 -0500
@@ -478,6 +478,12 @@
break; \
case S_VL: \
CHECK_b1; \
+ if (b1 <= (int) (a0 + TabEnt->Param)) { \
+ if (b1 < (int) (a0 + TabEnt->Param) || pa != thisrun) { \
+ unexpected("VL", a0); \
+ goto eol2d; \
+ } \
+ } \
SETVALUE(b1 - a0 - TabEnt->Param); \
b1 -= *--pb; \
break; \

53
libtiff-CVE-2011-1167.patch
View File

@ -1,53 +0,0 @@
Upstream patch for CVE-2011-1167, heap-based buffer overflow in thunder
decoder (ZDI-CAN-1004).
diff -Naur tiff-3.9.4.orig/libtiff/tif_thunder.c tiff-3.9.4/libtiff/tif_thunder.c
--- tiff-3.9.4.orig/libtiff/tif_thunder.c 2010-06-08 14:50:43.000000000 -0400
+++ tiff-3.9.4/libtiff/tif_thunder.c 2011-03-18 12:17:13.635796403 -0400
@@ -55,12 +55,32 @@
static const int twobitdeltas[4] = { 0, 1, 0, -1 };
static const int threebitdeltas[8] = { 0, 1, 2, 3, 0, -3, -2, -1 };
-#define SETPIXEL(op, v) { \
- lastpixel = (v) & 0xf; \
- if (npixels++ & 1) \
- *op++ |= lastpixel; \
- else \
+#define SETPIXEL(op, v) { \
+ lastpixel = (v) & 0xf; \
+ if ( npixels < maxpixels ) \
+ { \
+ if (npixels++ & 1) \
+ *op++ |= lastpixel; \
+ else \
op[0] = (tidataval_t) (lastpixel << 4); \
+ } \
+}
+
+static int
+ThunderSetupDecode(TIFF* tif)
+{
+ static const char module[] = "ThunderSetupDecode";
+
+ if( tif->tif_dir.td_bitspersample != 4 )
+ {
+ TIFFErrorExt(tif->tif_clientdata, module,
+ "Wrong bitspersample value (%d), Thunder decoder only supports 4bits per sample.",
+ (int) tif->tif_dir.td_bitspersample );
+ return 0;
+ }
+
+
+ return (1);
}
static int
@@ -151,6 +171,7 @@
(void) scheme;
tif->tif_decoderow = ThunderDecodeRow;
tif->tif_decodestrip = ThunderDecodeRow;
+ tif->tif_setupdecode = ThunderSetupDecode;
return (1);
}
#endif /* THUNDER_SUPPORT */

16
libtiff-acversion.patch
View File

@ -1,16 +0,0 @@
This patch is needed for building the package as of F-11. It can be
dropped whenever autoconf 2.63 is no longer used on any live branch.
diff -Naur tiff-3.9.4.orig/configure.ac tiff-3.9.4/configure.ac
--- tiff-3.9.4.orig/configure.ac 2010-06-15 14:58:12.000000000 -0400
+++ tiff-3.9.4/configure.ac 2010-06-15 17:13:11.000000000 -0400
@@ -24,7 +24,7 @@
dnl Process this file with autoconf to produce a configure script.
-AC_PREREQ(2.64)
+AC_PREREQ(2.63)
AC_INIT([LibTIFF Software],[3.9.4],[tiff@lists.maptools.org],[tiff])
AC_CONFIG_AUX_DIR(config)
AC_CONFIG_MACRO_DIR(m4)

48
libtiff-checkbytecount.patch
View File

@ -1,48 +0,0 @@
Upstream fix for bug #603024 is incomplete, tif_ojpeg.c should guard against
missing strip byte counts too. Testing shows that tiffsplit.c has an issue
too.
Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=1996
diff -Naur tiff-3.9.4.orig/libtiff/tif_ojpeg.c tiff-3.9.4/libtiff/tif_ojpeg.c
--- tiff-3.9.4.orig/libtiff/tif_ojpeg.c 2010-06-08 19:29:51.000000000 -0400
+++ tiff-3.9.4/libtiff/tif_ojpeg.c 2010-06-22 11:25:17.579807706 -0400
@@ -1920,6 +1920,10 @@
sp->in_buffer_file_pos=0;
else
{
+ if (sp->tif->tif_dir.td_stripbytecount == 0) {
+ TIFFErrorExt(sp->tif->tif_clientdata,sp->tif->tif_name,"Strip byte counts are missing");
+ return(0);
+ }
sp->in_buffer_file_togo=sp->tif->tif_dir.td_stripbytecount[sp->in_buffer_next_strile];
if (sp->in_buffer_file_togo==0)
sp->in_buffer_file_pos=0;
diff -Naur tiff-3.9.4.orig/tools/tiffsplit.c tiff-3.9.4/tools/tiffsplit.c
--- tiff-3.9.4.orig/tools/tiffsplit.c 2010-06-08 14:50:44.000000000 -0400
+++ tiff-3.9.4/tools/tiffsplit.c 2010-06-22 12:23:23.258823151 -0400
@@ -237,7 +237,10 @@
tstrip_t s, ns = TIFFNumberOfStrips(in);
uint32 *bytecounts;
- TIFFGetField(in, TIFFTAG_STRIPBYTECOUNTS, &bytecounts);
+ if (!TIFFGetField(in, TIFFTAG_STRIPBYTECOUNTS, &bytecounts)) {
+ fprintf(stderr, "tiffsplit: strip byte counts are missing\n");
+ return (0);
+ }
for (s = 0; s < ns; s++) {
if (bytecounts[s] > (uint32)bufsize) {
buf = (unsigned char *)_TIFFrealloc(buf, bytecounts[s]);
@@ -267,7 +270,10 @@
ttile_t t, nt = TIFFNumberOfTiles(in);
uint32 *bytecounts;
- TIFFGetField(in, TIFFTAG_TILEBYTECOUNTS, &bytecounts);
+ if (!TIFFGetField(in, TIFFTAG_TILEBYTECOUNTS, &bytecounts)) {
+ fprintf(stderr, "tiffsplit: tile byte counts are missing\n");
+ return (0);
+ }
for (t = 0; t < nt; t++) {
if (bytecounts[t] > (uint32) bufsize) {
buf = (unsigned char *)_TIFFrealloc(buf, bytecounts[t]);

48
libtiff-getimage-64bit.patch
View File

@ -1,48 +0,0 @@
Fix misbehavior on 64-bit machines when trying to flip a downsampled image
vertically: unsigned ints will be widened to 64 bits the wrong way.
See RH bug #583081.
Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2207
diff -Naur tiff-3.9.2.orig/libtiff/tif_getimage.c tiff-3.9.2/libtiff/tif_getimage.c
--- tiff-3.9.2.orig/libtiff/tif_getimage.c 2009-08-30 12:21:46.000000000 -0400
+++ tiff-3.9.2/libtiff/tif_getimage.c 2010-06-10 15:07:28.000000000 -0400
@@ -1846,6 +1846,7 @@
DECLAREContigPutFunc(putcontig8bitYCbCr22tile)
{
uint32* cp2;
+ int32 incr = 2*toskew+w;
(void) y;
fromskew = (fromskew / 2) * 6;
cp2 = cp+w+toskew;
@@ -1872,8 +1873,8 @@
cp2 ++ ;
pp += 6;
}
- cp += toskew*2+w;
- cp2 += toskew*2+w;
+ cp += incr;
+ cp2 += incr;
pp += fromskew;
h-=2;
}
@@ -1939,6 +1940,7 @@
DECLAREContigPutFunc(putcontig8bitYCbCr12tile)
{
uint32* cp2;
+ int32 incr = 2*toskew+w;
(void) y;
fromskew = (fromskew / 2) * 4;
cp2 = cp+w+toskew;
@@ -1953,8 +1955,8 @@
cp2 ++;
pp += 4;
} while (--x);
- cp += toskew*2+w;
- cp2 += toskew*2+w;
+ cp += incr;
+ cp2 += incr;
pp += fromskew;
h-=2;
}

22
libtiff-gif2tiff-overrun.patch
View File

@ -1,22 +0,0 @@
gif2tiff buffer overrun. Filed upstream at
http://bugzilla.maptools.org/show_bug.cgi?id=2270
This appears not to be security critical: it's a read not a write
overrun, so the worst possible consequence is SIGSEGV, and even that
doesn't seem to happen on any popular architectures.
diff -Naur tiff-3.9.4.orig/tools/gif2tiff.c tiff-3.9.4/tools/gif2tiff.c
--- tiff-3.9.4.orig/tools/gif2tiff.c 2010-06-08 14:50:44.000000000 -0400
+++ tiff-3.9.4/tools/gif2tiff.c 2010-11-02 22:32:10.018264489 -0400
@@ -503,6 +503,10 @@
strip = 0;
stripsize = TIFFStripSize(tif);
for (row=0; row<height; row += rowsperstrip) {
+ if (rowsperstrip > height-row) {
+ rowsperstrip = height-row;
+ stripsize = TIFFVStripSize(tif, rowsperstrip);
+ }
if (TIFFWriteEncodedStrip(tif, strip, newras+row*width, stripsize) < 0)
break;
strip++;

17
libtiff-mantypo.patch
View File

@ -1,17 +0,0 @@
Minor typo, reported upstream at
http://bugzilla.maptools.org/show_bug.cgi?id=2129
This patch should not be needed as of libtiff 4.0.
diff -Naur tiff-3.9.2.orig/man/tiffset.1 tiff-3.9.2/man/tiffset.1
--- tiff-3.9.2.orig/man/tiffset.1 2006-04-20 08:17:19.000000000 -0400
+++ tiff-3.9.2/man/tiffset.1 2009-12-03 12:11:58.000000000 -0500
@@ -60,7 +60,7 @@
``Anonymous'':
.RS
.nf
-tiffset \-s 305 Anonymous a.tif
+tiffset \-s 315 Anonymous a.tif
.fi
.RE
.PP

72
libtiff-scanlinesize.patch
View File

@ -1,72 +0,0 @@
Partial fix for issues filed upstream at
http://bugzilla.maptools.org/show_bug.cgi?id=2140
This stops the tiffcmp core dump noted in bug #460322, but isn't enough
to make tiffcmp return the right answer (it emits a bunch of error
messages instead).
diff -Naur tiff-3.9.2.orig/libtiff/tif_jpeg.c tiff-3.9.2/libtiff/tif_jpeg.c
--- tiff-3.9.2.orig/libtiff/tif_jpeg.c 2009-08-30 12:21:46.000000000 -0400
+++ tiff-3.9.2/libtiff/tif_jpeg.c 2010-01-05 22:40:40.000000000 -0500
@@ -988,8 +988,15 @@
tsize_t nrows;
(void) s;
- /* data is expected to be read in multiples of a scanline */
- if ( (nrows = sp->cinfo.d.image_height) ) {
+ nrows = cc / sp->bytesperline;
+ if (cc % sp->bytesperline)
+ TIFFWarningExt(tif->tif_clientdata, tif->tif_name, "fractional scanline not read");
+
+ if( nrows > (int) sp->cinfo.d.image_height )
+ nrows = sp->cinfo.d.image_height;
+
+ /* data is expected to be read in multiples of a scanline */
+ if (nrows) {
/* Cb,Cr both have sampling factors 1, so this is correct */
JDIMENSION clumps_per_line = sp->cinfo.d.comp_info[1].downsampled_width;
int samples_per_clump = sp->samplesperclump;
@@ -1087,8 +1094,7 @@
* TODO: resolve this */
buf += sp->bytesperline;
cc -= sp->bytesperline;
- nrows -= sp->v_sampling;
- } while (nrows > 0);
+ } while (--nrows > 0);
#ifdef JPEG_LIB_MK1
_TIFFfree(tmpbuf);
diff -Naur tiff-3.9.2.orig/libtiff/tif_strip.c tiff-3.9.2/libtiff/tif_strip.c
--- tiff-3.9.2.orig/libtiff/tif_strip.c 2006-03-25 13:04:35.000000000 -0500
+++ tiff-3.9.2/libtiff/tif_strip.c 2010-01-05 21:39:20.000000000 -0500
@@ -238,23 +238,19 @@
ycbcrsubsampling + 0,
ycbcrsubsampling + 1);
- if (ycbcrsubsampling[0] == 0) {
+ if (ycbcrsubsampling[0]*ycbcrsubsampling[1] == 0) {
TIFFErrorExt(tif->tif_clientdata, tif->tif_name,
"Invalid YCbCr subsampling");
return 0;
}
- scanline = TIFFroundup(td->td_imagewidth,
+ /* number of sample clumps per line */
+ scanline = TIFFhowmany(td->td_imagewidth,
ycbcrsubsampling[0]);
- scanline = TIFFhowmany8(multiply(tif, scanline,
- td->td_bitspersample,
- "TIFFScanlineSize"));
- return ((tsize_t)
- summarize(tif, scanline,
- multiply(tif, 2,
- scanline / ycbcrsubsampling[0],
- "TIFFVStripSize"),
- "TIFFVStripSize"));
+ /* number of samples per line */
+ scanline = multiply(tif, scanline,
+ ycbcrsubsampling[0]*ycbcrsubsampling[1] + 2,
+ "TIFFScanlineSize");
} else {
scanline = multiply(tif, td->td_imagewidth,
td->td_samplesperpixel,

51
libtiff-subsampling.patch
View File

@ -1,51 +0,0 @@
Use the spec-mandated default YCbCrSubSampling values in strip size
calculations, if the YCBCRSUBSAMPLING tag hasn't been provided.
See bug #603703.
Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2215
NB: must be applied after libtiff-scanlinesize.patch to avoid fuzz issues.
diff -Naur tiff-3.9.2.orig/libtiff/tif_strip.c tiff-3.9.2/libtiff/tif_strip.c
--- tiff-3.9.2.orig/libtiff/tif_strip.c 2006-03-25 13:04:35.000000000 -0500
+++ tiff-3.9.2/libtiff/tif_strip.c 2010-06-14 12:00:49.000000000 -0400
@@ -124,9 +124,9 @@
uint16 ycbcrsubsampling[2];
tsize_t w, scanline, samplingarea;
- TIFFGetField( tif, TIFFTAG_YCBCRSUBSAMPLING,
- ycbcrsubsampling + 0,
- ycbcrsubsampling + 1 );
+ TIFFGetFieldDefaulted(tif, TIFFTAG_YCBCRSUBSAMPLING,
+ ycbcrsubsampling + 0,
+ ycbcrsubsampling + 1);
samplingarea = ycbcrsubsampling[0]*ycbcrsubsampling[1];
if (samplingarea == 0) {
@@ -234,9 +234,9 @@
&& !isUpSampled(tif)) {
uint16 ycbcrsubsampling[2];
- TIFFGetField(tif, TIFFTAG_YCBCRSUBSAMPLING,
- ycbcrsubsampling + 0,
- ycbcrsubsampling + 1);
+ TIFFGetFieldDefaulted(tif, TIFFTAG_YCBCRSUBSAMPLING,
+ ycbcrsubsampling + 0,
+ ycbcrsubsampling + 1);
if (ycbcrsubsampling[0]*ycbcrsubsampling[1] == 0) {
TIFFErrorExt(tif->tif_clientdata, tif->tif_name,
@@ -308,9 +308,9 @@
&& !isUpSampled(tif)) {
uint16 ycbcrsubsampling[2];
- TIFFGetField(tif, TIFFTAG_YCBCRSUBSAMPLING,
- ycbcrsubsampling + 0,
- ycbcrsubsampling + 1);
+ TIFFGetFieldDefaulted(tif, TIFFTAG_YCBCRSUBSAMPLING,
+ ycbcrsubsampling + 0,
+ ycbcrsubsampling + 1);
if (ycbcrsubsampling[0]*ycbcrsubsampling[1] == 0) {
TIFFErrorExt(tif->tif_clientdata, tif->tif_name,

35
libtiff-tiffdump.patch
View File

@ -1,35 +0,0 @@
Make tiffdump more paranoid about checking the count field of a directory
entry.
Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2218
diff -Naur tiff-3.9.4.orig/tools/tiffdump.c tiff-3.9.4/tools/tiffdump.c
--- tiff-3.9.4.orig/tools/tiffdump.c 2010-06-08 14:50:44.000000000 -0400
+++ tiff-3.9.4/tools/tiffdump.c 2010-06-22 12:51:42.207932477 -0400
@@ -46,6 +46,7 @@
# include <io.h>
#endif
+#include "tiffiop.h"
#include "tiffio.h"
#ifndef O_BINARY
@@ -317,7 +318,7 @@
printf(">\n");
continue;
}
- space = dp->tdir_count * datawidth[dp->tdir_type];
+ space = TIFFSafeMultiply(int, dp->tdir_count, datawidth[dp->tdir_type]);
if (space <= 0) {
printf(">\n");
Error("Invalid count for tag %u", dp->tdir_tag);
@@ -709,7 +710,7 @@
w = (dir->tdir_type < NWIDTHS ? datawidth[dir->tdir_type] : 0);
cc = dir->tdir_count * w;
if (lseek(fd, (off_t)dir->tdir_offset, 0) != (off_t)-1
- && read(fd, cp, cc) != -1) {
+ && read(fd, cp, cc) == cc) {
if (swabflag) {
switch (dir->tdir_type) {
case TIFF_SHORT:

47
libtiff-unknown-fix.patch
View File

@ -1,47 +0,0 @@
Ooops, previous fix to unknown-tag handling caused TIFFReadDirectory to
sometimes complain about out-of-order tags when there weren't really any.
Fix by decoupling that logic from the tag search logic.
Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2210
diff -Naur tiff-3.9.4.orig/libtiff/tif_dirread.c tiff-3.9.4/libtiff/tif_dirread.c
--- tiff-3.9.4.orig/libtiff/tif_dirread.c 2010-06-14 10:27:51.000000000 -0400
+++ tiff-3.9.4/libtiff/tif_dirread.c 2010-06-16 01:27:03.000000000 -0400
@@ -83,6 +83,7 @@
const TIFFFieldInfo* fip;
size_t fix;
uint16 dircount;
+ uint16 previous_tag = 0;
int diroutoforderwarning = 0, compressionknown = 0;
int haveunknowntags = 0;
@@ -163,23 +164,24 @@
if (dp->tdir_tag == IGNORE)
continue;
- if (fix >= tif->tif_nfields)
- fix = 0;
/*
* Silicon Beach (at least) writes unordered
* directory tags (violating the spec). Handle
* it here, but be obnoxious (maybe they'll fix it?).
*/
- if (dp->tdir_tag < tif->tif_fieldinfo[fix]->field_tag) {
+ if (dp->tdir_tag < previous_tag) {
if (!diroutoforderwarning) {
TIFFWarningExt(tif->tif_clientdata, module,
"%s: invalid TIFF directory; tags are not sorted in ascending order",
tif->tif_name);
diroutoforderwarning = 1;
}
- fix = 0; /* O(n^2) */
}
+ previous_tag = dp->tdir_tag;
+ if (fix >= tif->tif_nfields ||
+ dp->tdir_tag < tif->tif_fieldinfo[fix]->field_tag)
+ fix = 0; /* O(n^2) */
while (fix < tif->tif_nfields &&
tif->tif_fieldinfo[fix]->field_tag < dp->tdir_tag)
fix++;

35
libtiff-ycbcr-clamp.patch
View File

@ -1,35 +0,0 @@
Using an array to clamp translated YCbCr values is insecure, because if the
TIFF file contains bogus ReferenceBlackWhite parameters, the computed RGB
values could be very far out of range (much further than the current array
size, anyway), possibly resulting in SIGSEGV. Just drop the whole idea in
favor of using a comparison-based macro to clamp. See RH bug #583081.
Filed upstream at http://bugzilla.maptools.org/show_bug.cgi?id=2208
diff -Naur tiff-3.9.2.orig/libtiff/tif_color.c tiff-3.9.2/libtiff/tif_color.c
--- tiff-3.9.2.orig/libtiff/tif_color.c 2006-02-09 10:42:20.000000000 -0500
+++ tiff-3.9.2/libtiff/tif_color.c 2010-06-10 15:53:24.000000000 -0400
@@ -183,13 +183,18 @@
TIFFYCbCrtoRGB(TIFFYCbCrToRGB *ycbcr, uint32 Y, int32 Cb, int32 Cr,
uint32 *r, uint32 *g, uint32 *b)
{
+ int32 i;
+
/* XXX: Only 8-bit YCbCr input supported for now */
Y = HICLAMP(Y, 255), Cb = CLAMP(Cb, 0, 255), Cr = CLAMP(Cr, 0, 255);
- *r = ycbcr->clamptab[ycbcr->Y_tab[Y] + ycbcr->Cr_r_tab[Cr]];
- *g = ycbcr->clamptab[ycbcr->Y_tab[Y]
- + (int)((ycbcr->Cb_g_tab[Cb] + ycbcr->Cr_g_tab[Cr]) >> SHIFT)];
- *b = ycbcr->clamptab[ycbcr->Y_tab[Y] + ycbcr->Cb_b_tab[Cb]];
+ i = ycbcr->Y_tab[Y] + ycbcr->Cr_r_tab[Cr];
+ *r = CLAMP(i, 0, 255);
+ i = ycbcr->Y_tab[Y]
+ + (int)((ycbcr->Cb_g_tab[Cb] + ycbcr->Cr_g_tab[Cr]) >> SHIFT);
+ *g = CLAMP(i, 0, 255);
+ i = ycbcr->Y_tab[Y] + ycbcr->Cb_b_tab[Cb];
+ *b = CLAMP(i, 0, 255);
}
/*

36
libtiff.spec
View File

@ -1,26 +1,13 @@
Summary: Library of functions for manipulating TIFF format image files
Name: libtiff
Version: 3.9.4
Release: 4%{?dist}
Version: 3.9.5
Release: 1%{?dist}
License: libtiff
Group: System Environment/Libraries
URL: http://www.remotesensing.org/libtiff/
Source: ftp://ftp.remotesensing.org/pub/libtiff/tiff-%{version}.tar.gz
Patch1: libtiff-acversion.patch
Patch2: libtiff-mantypo.patch
Patch3: libtiff-scanlinesize.patch
Patch4: libtiff-getimage-64bit.patch
Patch5: libtiff-ycbcr-clamp.patch
Patch6: libtiff-3samples.patch
Patch7: libtiff-subsampling.patch
Patch8: libtiff-unknown-fix.patch
Patch9: libtiff-checkbytecount.patch
Patch10: libtiff-tiffdump.patch
Patch11: libtiff-CVE-2011-0192.patch
Patch12: libtiff-CVE-2011-1167.patch
Patch13: libtiff-gif2tiff-overrun.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
BuildRequires: zlib-devel libjpeg-devel
@ -73,20 +60,6 @@ image files using the libtiff library.
%prep
%setup -q -n tiff-%{version}
%patch1 -p1
%patch2 -p1
%patch3 -p1
%patch4 -p1
%patch5 -p1
%patch6 -p1
%patch7 -p1
%patch8 -p1
%patch9 -p1
%patch10 -p1
%patch11 -p1
%patch12 -p1
%patch13 -p1
# Use build system's libtool.m4, not the one in the package.
rm -f libtool.m4
@ -197,6 +170,11 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/*
%changelog
* Tue Apr 12 2011 Tom Lane <tgl@redhat.com> 3.9.5-1
- Update to libtiff 3.9.5, incorporating all our previous patches plus other
fixes, notably the fix for CVE-2009-5022
Related: #695885
* Mon Mar 21 2011 Tom Lane <tgl@redhat.com> 3.9.4-4
- Fix incorrect fix for CVE-2011-0192
Resolves: #684007

2
sources
View File

@ -1 +1 @@
2006c1bdd12644dbf02956955175afd6 tiff-3.9.4.tar.gz
8fc7ce3b4e1d0cc8a319336967815084 tiff-3.9.5.tar.gz