2024.02.03 15:00 "[Tiff] www.libtiff.org is restored", by Bob Friesenhahn

2024.02.04 21:15 "Re: [Tiff] www.libtiff.org is restored", by Lee Howard

>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.
  2. 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.)
  3. 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.