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

Reply via email to