If the tiff utilities are moved to their own project, how closely would they need to track changes in the libtiff api or to support different versions of libtiff?
I thought that the tiff utility programs were, in part, examples showing best practice in using libtiff, so there is a benefit to having the utilities in libtiff or connected to it. First time users of libtiff probably look at how the utilities work. What percentage of the tiff utility CVEs are coding errors in the utilities compared to issues that the utilities expose in libtiff? I use tiff2ps. If you split the utilities into their own project, I would be willing to be on the list of people who help with CVEs. William ________________________________ From: Tiff <[email protected]> on behalf of Even Rouault via Tiff <[email protected]> Sent: Sunday, February 4, 2024 9:23 AM To: Bob Friesenhahn <[email protected]>; Patrice Fournier via Tiff <[email protected]> Subject: Re: [Tiff] www.libtiff.org is restored Hi, > It is useful to be aware of the underlying reasons why utilities were > removed from libtiff. Whenever a security issue is identified related > to software produced by the libtiff project, a CVE was created against > libtiff, since the utility was released as part of libtiff. > Proprietary and free operating system and application distributions > which include libtiff then had a huge red flag assigned to them, which > demands action. The utilities were continually having CVEs at the > most severe levels written against them. I concur with that. > > It is also a fact that several people maintaining core libtiff > primarily care about the library and not these old utilities. I'm one of those people. I personally only use libtiff, and occasionally for debugging purposes tiffdump and tiffinfo. Very very infrequently tiffset > > If the utilities are again maintained by the libtiff project, they > need to be in a separate repository, with its own build process, and > released distinctly from libtiff. If this approach is not acceptable > to libtiff maintainers, then the tools would need to be hosted elsewhere. My own preference would be for a separate repository too. That would avoid libtiff-the-lib to be perceived as being affected by issues specific to the utilities, and would allow people interested in the utilities to do releases at their own pace. One "little detail" though that can go against moving them to a separate repo is that most of those utilities include "tiffiop.h", a private non-installed header. But I suspect/hope that in most time it is an oversight, and that dependency could easily be removed (although some fax related utilities might use internal details of the fax codec). I'm not entirely closed to the idea of motivated volunteers trying to resurrect a subset of those utilities in libtiff main repo, but they must be ready to do a very significant amount work to address those already reported vulnerabilities, and the ones that will for sure come in the future. One thing that make it hard to maintain the utilities is that they have very little regression tests (to be fair, the library itself could be more tested too, and there has certainly been effort in adding unit tests recently for modified/added functionality), so any security patching made by people not familiar with them had the opportunity to break things. Regards, Even -- 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
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
