Even Rouault (bb1ff4f8) at 19 Mar 08:37
Merge branch 'chore/printf-format-specifiers' into 'master'
... and 1 more commit
When building on my Mac, I get the following warnings:
libtiff/tools/tiffcp.c:154:24: warning: format specifies type 'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int') [-Wformat]
comma, nextImage);
^~~~~~~~~
libtiff/tools/tiffcp.c:1295:39: warning: format specifies type 'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int') [-Wformat]
TIFFFileName(bias), TIFFCurrentDirectory(bias),
^~~~~~~~~~~~~~~~~~~~~~~~~~
libtiff/tools/tiffcp.c:1296:37: warning: format specifies type 'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int') [-Wformat]
TIFFFileName(in), TIFFCurrentDirectory(in));
^~~~~~~~~~~~~~~~~~~~~~~~
libtiff/tools/tiffcp.c:1303:37: warning: format specifies type 'unsigned short' but the argument has type 'tdir_t' (aka 'unsigned int') [-Wformat]
TIFFFileName(in), TIFFCurrentDirectory(in));
^~~~~~~~~~~~~~~~~~~~~~~~
libtiff/tools/tiffsplit.c:174:21: warning: format specifies type 'long long' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
path_len);
^~~~~~~~
This updates the format specifiers from PRIu16
to PRIu32
for tdir_t
(which is a typdef
ed uint32_t
) and from TIFF_SSIZE_FORMAT
to
TIFF_SIZE_FORMAT
for size_t
, which makes sense given that it's an unsigned
type.
thanks
I would say that fuzz testing of a utility should fuzz both command line arguments and the fuzzed file, because bugs may only happen in certain combinations of both. That said, with my knowledge of ossufzz, direct testing of command line utilities is not possible, since the entry point of OSSFuzz is the LLVMFuzzerTestOneInput(const uint8_t *buf, size_t len) function which must be able to be invoked multiple times per process. So there might be preliminary work to make it possible to build the utilities with an adapter layer compatible of such an interface (and make sure the utilities never call exit()...)". For the GDAL project, for other reasons, we have already a library compatible way of invoking most utilities, so we have been able to fuzz them, and we split the fuzzed buffer in 2 parts, one that is for the arguments, and the other one for the data (that is done in a slightly different way, considering the buffer as a kind of TAR archive, but you get the idea). For example, in https://github.com/OSGeo/gdal/blob/master/fuzzers/gdal_vector_translate_fuzzer.cpp . There would be """some""" work to adapt that for libtiff utilities. I believe most people who have fuzzed libtiff utilities up to now have been using AFL (https://lcamtuf.coredump.cx/afl/) locally, which require little to none code change.
I'm wondering if those new fields shouldn't rather be in the TIFFDirectory structure, as they are specific of a given IFD
I can see at least a few error code paths (like at line 5139, 5148 and 5156) that don't "goto bad", and should probably.
More generally it would be also safer to insert such cleanup in a "strategic" cleanup function. Perhaps TIFFFreeDirectory ?
if (tif->tif_dirdatasize_offsets != NULL)
{
_TIFFfreeExt(tif, tif->tif_dirdatasize_offsets);
tif->tif_dirdatasize_offsets = NULL;
}
if (tif->tif_dirdatasize_offsets != NULL)
{
_TIFFfreeExt(tif, tif->tif_dirdatasize_offsets);
tif->tif_dirdatasize_offsets = NULL;
}
why 1024 ? Wouldn't it be robust to set tif->tif_dirdatasize_read to UINT64_MAX for example ?
Null pointer checks here are unneeded. qsort() can't call this function with nullptr.
I've trouble understanding this sentence. It could probably be reworded
Even Rouault (2005dbb4) at 16 Mar 17:23
Merge branch 'fix_628_FPE_at_TIFFhowmany' into 'master'
... and 1 more commit
Avoiding FPE (division by zero) for TIFFhowmany_32() and TIFFhowmany_64() macros by checking for denominator not zero before macros are executed. Fixes #628.
Even Rouault (025467ab) at 14 Mar 20:35
Merge branch 'fix_wrong_return_TIFFIsBigTIFF_if_swapping_case' into...
... and 1 more commit
Fix wrong return of TIFFIsBigTIFF() in case byte-swapping is acitve (i.e. little endian image on a big endian machine).
The content of tif_header.common.tiff_version is equivalent to the file value (not swapped) and therefore a comparison (==) with TIFF_VERSION_BIG will fail for all images where swapping is required. The MR does the job without need of swapping.
Could we put here a direct reference to "tiff@lists.osgeo.org" and "http://www.awaresystems.be/imaging/tiff/tml.html"?
done
Also this will need a reference. The :ref:"rfcs" does not work at the moment (plain text in the html).
ah, I add forgotten to commit doc/rfcs/index.rst. Done
How would someone find the current ongoing "PSC discussions" on the "mailing list"? Will there be a page with a list of RFCs as a reference / link to the PSC discussions and PSCs itself?
Approved RFCs will be linked in index.rst. I would expect draft/in-progress RFCs to be dealt as gitlab MR, and announced on the mailing list, just as this one.
This has to be finalized with the nominated Chair.
Do we have volunteer(s)?