>Unfortunately, the demoted tools do not only use tiffconf.h. Some of them >rely heavily on libtiff internals. It wouldn't be a simple process to >separate the tools from the rest of libtiff.
I didn't realize that. I think that is worth fixing. The utilities can't be examples of best use of libtiff if they access libtiff internals that normal applications can't use. Possibly other users of libtiff are forced into accessing the same libtiff internals, and it might help libtiff users if everything required to implement the utilities was part of the stable public api. Is it more complicated than trying to build the utilities with just the public header files to see what breaks, and then moving some declarations or wrappers to access them to a public header? >Fork libtiff How about setting up the utilities as a git repo that builds with libtiff as a submodule? The utilities would be able to reference a specific commit of libtiff, so they could access libtiff internals safely. >I have been trying to rally people interested in doing the work to fix the >security issues. I could probably handle an occasional request with a cve and example tiff that is reproducible on Linux x86_64. William ________________________________ From: Lee Howard <fax...@howardsilvan.com> Sent: Sunday, February 4, 2024 4:15 PM To: William Bader <williamba...@hotmail.com>; Bob Friesenhahn <bfrie...@simple.dallas.tx.us>; Rob Tillaart <rob.tilla...@gmail.com> Cc: Patrice Fournier via Tiff <tiff@lists.osgeo.org> Subject: Re: [Tiff] www.libtiff.org is restored On 2/4/24 8:11 AM, William Bader via Tiff wrote: >If the utilities are again maintained by the libtiff project, they need to be in a separate repository, with its own build process Shouldn't the build for the utilities be simpler than the build for libtiff because the utilities only use tiffconf.h instead of generating it? The utilities should be best use examples for libtiff, and something might be wrong if they end up needing a massively complicated build process. Unfortunately, the demoted tools do not only use tiffconf.h. Some of them rely heavily on libtiff internals. It wouldn't be a simple process to separate the tools from the rest of libtiff. I understand and hear the opinions about having the tools be in a separate repository maintained by separate people, etc., but the tools can't really be ripped out of the library source and compile at all. To maintain the tools would necessarily require maintaining the library. The tools are integrated into the library source. The only paths forward that I can visualize would be: 1) Fix the security issues in the tools, commit to maintaining them long term, and restore the tools to the package as they were previously. This is what I had understood was acceptable to Even and Sulau. (And I'm a bit discouraged about slight backpedaling I'm hearing in this thread.) 2) Fork libtiff - one with the tools, and one without. (And the one with the tools would necessarily duplicate the one without.) Distributions would either need to choose between the two or package both in ways in which they wouldn't conflict, e.g., libtiff45 and libtiff. Again, I had heard that #1 was acceptable, and I have been trying to rally people interested in doing the work to fix the security issues. I'll do all of that work, myself, if I ultimately have to (once I can get some priority work out of the way first). I find it frustrating to hear comments here from dev team members suggesting that #1 is now not acceptable. I am in no way interested in #2. However, if #1 will never, ever happen then I am faced with no other practical option. Thanks, Lee.
_______________________________________________ Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff
