Hi,
I admire Su's tenacity in trying to fix tiffcrop issues over the past
years, and I certainly share his point of view. The vast majority of
recent libtiff related CVEs in recent years are not in libtiff itself,
but in its utilities. Personally I don't care about libtiff utilities
(perhaps except tiffinfo and tiffdump for debugging purposes), just the lib.
I guess tiffcrop could receive the same treatment as a few past
utilities that have been migrated to archive/tools/ where only the
source code is there without any build system support.
tiff2ps and tiff2pdf seem to be also good candidates for moving into
archive as they have a number of reported security related issues and a
significant code size. Their functionality is (at least mostly) covered
by the convert utility of ImageMagick.
Even
Le 03/04/2023 à 22:50, Sulau a écrit :
Dear all
I have been trying to fix the constant CVE issues at tiffcrop for
several years.
Today I can say "fixing is not possible".
The endless combinable parameters and the grown implementation of the
working buffer allocation for input, intermediate results and output
make maintenance nearly impossible.
Also the code often (partially) does something different than I would
expect based on the parameter description. This is then often visible
in the resulting image, which looks different than what the very brief
parameter description would suggest.
With this in mind, I would recommend removing tiffcrop from the
LibTiff library to avoid endless CVE and buffer overrun issues that
are not really part of LibTiff.
Regards
Su
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff